January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo 1.1 failing tests testBlockNumbering

by Nicolas Cellier

Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs But then, method still fails because keys does not answer a Set anymore. Use keys asSet. Nicolas 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > The test is incompatible with new CompiledMethod trailer > Use generate rather than generate: #(0 0 0 0) > > Then the method still fails because sending unimplemented > #blockExtentsToTempRefs > > same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto > > Nicolas >

Jan. 16, 2010

[Pharo-project] Pharo 1.1 failing tests testBlockNumbering

by Nicolas Cellier

The test is incompatible with new CompiledMethod trailer Use generate rather than generate: #(0 0 0 0) Then the method still fails because sending unimplemented #blockExtentsToTempRefs same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto Nicolas

Jan. 16, 2010

[Pharo-project] Pharo 1.1 failing tests testNewLineStartsIndentedWhenWrapped

by Nicolas Cellier

If paragraph composition width is reduced by 24 instead of 20, the test works (taken from trunk) testNewLineStartsIndentedWhenWrapped "Checks whether the beginning of a new line starts at the indented position" | cb | para compositionRectangle: (0@0 extent: para width - 24@100); updateCompositionHeight. para clippingRectangle: (0@0 extent: 200@200). cb := para characterBlockForIndex: 8. self assert: cb top > 0. self assert: cb left = 24

Jan. 16, 2010

Re: [Pharo-project] ConfigurationOfAlien

by Mariano Martinez Peck

Cool Fernando!!! But...ar you sure you commited ? ;) Because I don't see such methods like loadMacOSX loadLibC, etc... I checled in both urls: 'http://www.squeaksource.com/Alien' and MetacelloRepository cheers Mariano On Sat, Jan 16, 2010 at 1:19 PM, Fernando olivero <oliverof(a)lu.unisi.ch>wrote: > Hi, i've updated the ConfigurationOfAlien. > > I've added groups and load shortcuts to the class. > > Thanks Mariano for the tips on metacello. > > > John, I bother you once again, please put the new info on the page. > > > > To load Alien in a Pharo Dev image: > > Gofer new > url: 'http://www.squeaksource.com/Alien' ; > addPackage: 'ConfigurationOfAlien'; > load. > > Then evaluate the desired group/s: > > ConfigurationOfAlien loadCore. > > ConfigurationOfAlien loadTests. > > ConfigurationOfAlien loadLibC. > > ConfigurationOfAlien loadMacOSX. > > ConfigurationOfAlien loadVMMaker. > > ConfigurationOfAlien loadWin32. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 16, 2010

Re: [Pharo-project] Styles for Morphic

by Igor Stasenko

2010/1/16 Stan Shepherd <stan.shepherd414(a)gmail.com>: > > > Igor Stasenko wrote: >> >> Hello guys, >> >> thinking, how to easily define styles, based on simple selection rules, >> i sketched the class, MorphStyle. >> >> The principle how it works is simple: >> >> - you creating a style, add adding actions to it >> - you then applying style to morph or group of morphs. >> >> Example: >> >> | style | >> style := MorphStyle new >> Â Â Â submorphs >> Â Â Â model: #Browser; >> Â Â Â color: Color red. >> style applyTo: World. >> >> Let me describe in detail, what it does, when you applying it: >> >> style applyTo: World. >> >> Style initializing its current selection to be a collection with >> single element - { World }. >> Next thing, which it does is applying any actions , which we specified >> during building the style, >> namely: >> >> 'submorphs' - replacing the current selection by gathering all >> submorphs of it, i.e. >> >> selection before: >> Â #( World ) >> selection after: >> #( World's submorphs ) >> >> 'model: #Browser' Â - filter the current selection and leave only those >> entries, which respond to #model and model class name is #Browser >> >> selection before: >> #( world's submorphs ) >> selection after: >> { Browser SystemWindow#1. Browser SystemWindow#2. Browser >> SystemWindow#3.Browser SystemWindow#4. } >> >> >> 'color: Color red'. Â - since there's no such method in MorphStyle, it >> is trapped by DNU handler and >> Â converted to a #sendMessage: action. >> A #sendMessage: action sends a specified message to current selection, >> i.e.: >> >> { Browser SystemWindow#1. .... Browser SystemWindow#N. } >> do: [:morph | message sendTo: morph ]. >> >> So, as result, if you doIt : >> | style | >> style := MorphStyle new >> Â Â Â submorphs >> Â Â Â model: #Browser; >> Â Â Â color: Color red. >> style applyTo: World. >> >> all browser windows color will be changed to red color. >> >> Some words about potential uses of this stuff. >> >> - theming, Â (through defining own style sheets). In contrast to >> existing implementation, we're free to define anything, which morph >> understands , >> Â not just colors, border or fillstyle, but also, layout, fonts, >> position etc etc. >> >> - defining styles in various ways: >> following snippet sets the 'browse' button color to red for all >> browser windows and illustrating how one style could reuse another >> one. >> >> | browseButton buttonStyle browsers | >> >> buttonStyle := MorphStyle new color: Color blue. >> browseButton := MorphStyle new allSubmorphs; has: #label equalTo: >> 'browse'. >> browsers := MorphStyle new model: #Browser. >> >> browseButton style: buttonStyle. "browseButton reusing buttonStyle" >> browsers style: browseButton. Â "browser style reusing browseButton style" >> >> browsers applyTo: World submorphs. >> >> >> It can be easily integrated with Morphic when using some global theme, >> all we need is: >> - add Â Morph>>applyThemeStyles >> Â ^ World currentTheme applyStylesTo: self >> >> - send #applyStyles to morph, when its added to World. >> >> Also, we could integrate it with toolbuilder which will allow us to define >> morph layouts, fonts, colors & initial properties more flexibly than >> currently are . Non-morphic builders could just ignore the #setStyles: >> message. >> >> Comments, suggestions , as always welcome. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > +1 > > The builders and themes don't play nicely at present. > > There are 35 senders like: > > Â Â Â Â window := (SystemWindow labelled: labelString) model: self. > > So #labelled: creates a SystemWindow and asks the current UITheme to theme > it, before it has any information to do so (model is still nil). > > So having more dynamic styles like this sounds a good way to sort this; I > suspect it would also allow some theme related nasties to be removed. > In my other experiment, i introduced the modes stack for morphs. Initially, a morph has default mode, but once its interacting with user, its mode stack is changing, and this immediately reflects on morph's appearance. A morph's mode stack explained for a simple button: default default -> mouseover "mouse entering the button" default -> mouseover -> mousedown "user clicking a button" default "mouse leaved the button" now same but for disabled button: default -> disabled default -> disabled -> mouseover default -> disabled -> mouseover -> mousedown Now all we need is to define a style for each mode. The code, which draws the morph then asks a topmost style for some property. drawNormal: aCanvas | padding | " self debugDisplay: bounds corner printString." (mode styleAt: #hasDropShadow) ifTrue: [ self drawShadowOn: aCanvas. ]. aCanvas frameAndFillRectangle: (bounds origin extent: labelExtent) fillColor: (mode styleAt: #backgroundColor) borderWidth: (mode styleAt: #borderWidth ) borderColor: (mode styleAt: #borderColor). padding := mode styleAt: #labelPadding. aCanvas drawString: node label at: (bounds origin translateBy: padding) font: self font color: (mode styleAt: #labelColor). The property lookup semantics is simple: first it looks for property defined for topmost mode in stack, if not found, then it asks mode which lies down the stack, and so on, until it finds it in the default mode style. But that's not all, you can also control a method, which will draw the morph, depending on its current mode. The trick is simple: drawOn: aCanvas "Draw a morph by using method, supplied by current mode" | method | method := mode styleAt: #drawMethod. ^ self perform: method with: aCanvas So, depending on mode & its style it may issue #drawNormal, or #drawDisabled , or anything. A different drawing methods is useful, when you want to change the way how morph is drawn, i.e. draw ellipse instead of rectangle, or draw image instead of text etc. So, with given trick, you can control not only how you drawing the morph, but also what you drawing. I found that mode stack is most flexible way to control the morph's appearance. There is a tons of properties , held by morph, such as #hasShadow which is set by some controller. But the thing is, that this is wrong way to do that , because of the explosion of number of combinations: when you have 10 flags - you have 2^10 combinations. While with mode stack you simply pushing the #dropShadow mode into stack, and with corresponding style you can define new or override existing properties which control the morph's appearance. For example, your code using a #backgroundColor style property: MorphStyles at: #default put: ( SlimCascadingStyle new at: #fillColor put: (Color r: 235/255 g: 227/255 b: 103/255 ); at: #highlightColor put: (Color r: 251/255 g: 242/255 b: 110/255); at: #backgroundColor inherit: #fillColor ) But you want to use different background, when mouse hoveing over the morph: MorphStyles at: #mouseOver put: ( SlimCascadingStyle new " replace background color with highlight color" at: #backgroundColor inherit: #highlightColor; yourself). That's all :) Then code, which drawing the morph always looks clean , because you don't need to put messy things like: self isFoo ifTrue: [ self drawThis ] ifFalse: [ self drawThat]. self isBar ifTrue: [ self drawThis ] ifFalse: [ self drawThat]. ... It would be interesting to combine the 'Styles for Morphic' with 'Styles for mode stack' :) > ...Stan > > -- > View this message in context: http://n2.nabble.com/Styles-for-Morphic-tp4402731p4404007.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Jan. 16, 2010

[Pharo-project] Pharo 1.1 failing tests testIsUnsentMessagesInCategory

by Nicolas Cellier

testIsUnsentMessagesInCategory testIsUnsentMessagesInClass testIsUnsentMessagesInPackage all fail because selectors does not answer a Set anymore. Just add #asSet in the assertion and all will be OK Nicolas

Jan. 16, 2010

[Pharo-project] Pharo 1.1 failing tests testToDoOutsideTempNotInlined

by Nicolas Cellier

Sorry this is an effect of automatic move of temps inside blocks... testToDoOutsideTempNotInlined REQUIRES that | temp | be declared outside the block. Just revert to previous version from Lukas Nicolas

Jan. 16, 2010

[Pharo-project] Pharo 1.1 failing tests testOtherClasses

by Nicolas Cellier

DependentsArray is no more a subclass of ArrayedCollection. Apart this test, there is 0% chance to send byteSize nor bytesPerBasicElement to a DependentsArray. Simply remove DependentsArray from this test. Nicolas

Jan. 16, 2010

Re: [Pharo-project] Putting Algernon and WorkingSet in a Dev image

by Mariano Martinez Peck

Hi guys: Of course I would like having keymapper or similar working in Pharo, but as I always say, I rather go step by step. Last night, I was up to 2 am trying to get this working. I was almost there, but as I don't know everything about Morphic, I ask to you. What Simon said about the binary changeset of Algernon, is true. However, I took the time to analyze the changeset and from my point of view (nil knowledge in Morphic) it seemed a very good change. I fix it (it has underscore assignment) and I was easily merged to Pharo. No conflicts. The main change does the simplest modifications to HandMorph for it to support various focus holders. And I think this is cool. So, suppose we integrate this changeset, Algernon, wouldn't have any override the method sendKeyboardEvent: Now Romain, do you think that you can manage to get WorkingSet working with this change without overriding? Algernon does, so maybe we can see how it do it. I saw this: Algernon >> registerWithSystem There you will see it does a self activeHand addAdditionalKeyboardFocus: self. That method was part of the Morphic changes. I commit the Mprhic changes in http://www.squeaksource.com/MarianoPhD Name: Morphic-MarianoMartinezPeck.396 Author: MarianoMartinezPeck Time: 16 January 2010, 3:42:18 pm UUID: 3587e1b2-36b4-4751-bcdb-ca6f4073788e Ancestors: Morphic-MarianoMartinezPeck.395 Romain, can you take a look and if this is not enough, how can we solve easily this problem in Pharo? Thanks Mariano 2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> > > On 15 janv. 2010, at 23:03, Mariano Martinez Peck wrote: > > > > 2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> > >> >> On 15 janv. 2010, at 21:20, Mariano Martinez Peck wrote: >> >> >> >> On Fri, Jan 15, 2010 at 5:55 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: >> >>> yes it has overrides ... >>> >>> that's because as far as I know, there's no keyboard shortcut management >>> facility >>> in Pharo. If there was one, I suppose Algernon and WorkingSet would >>> coexist. >>> >> >> >> So...all your overrides are due to the shortcuts? I think it is not fear >> to "forbid" a package to be included in a Dev image if we don't provide from >> the core a way to manage shortcuts. So: >> >> 1) Or we let this projects to be installed in the Dev image >> >> 2) We fix the problem with the shortcuts. >> >> Romain: can you tell us where exactly the problem is ? maybe someone can >> give you a hand. >> >> >> >> Taking a look at that, there are 2 overrides in WorkingSet >> > > > How did you detect that ? > > > > Manually, using an extension-aware browser (O2Package, MC browse package, > or the package environment) to detect extensions, then check history in the > versions browser. > > > > Impressive. You should be a detective :) > > > > A few years ago, I was called the human debugger during a project :) Now I > try to restrain from this kind of sessions though, it's time consuming. > > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 16, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by GermÃ¡n Arduino

Hi: > 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Hi Folks/Beta-Testers! >> >> 6) There is no Web image this time. If you want to install Seaside 2.8.4 >> evaluate: >> >> Gofer new >> Â Â Â squeaksource: 'MetacelloRepository'; >> Â Â Â package: 'ConfigurationOfSeaside28'; >> Â Â Â load. >> >> (Smalltalk at: #ConfigurationOfSeaside28) load >> >> And if you want Seaside 3.0 evaluate: >> >> Gofer new >> Â Â Â squeaksource: 'MetacelloRepository'; >> Â Â Â package: 'ConfigurationOfSeaside30'; >> Â Â Â load. >> >> (Smalltalk at: #ConfigurationOfSeaside30) loadLatestVersion >> >> However, I am not sure if this is perfectly working in Pharo. I started today, with the intention of port a new system I'm developing directly to Seaside 3.0. All the installation seems to works ok, I must try more yet, but a thing I noticed is not included and should by (imho) is Magritte. Just my 0.02 Cheers. GermÃ¡n.

Jan. 16, 2010