- Pharo-dev - lists.pharo.org

Re: [Pharo-project] icons in pluggablelistmorph

by Tudor Girba

Thanks Lukas. Indeed, it is straightforward :). I will give it a try. Cheers, Doru On 11 Sep 2009, at 20:28, Lukas Renggli wrote: >> I would like to specify an icon in a PluggableListMorph, but I cannot >> find my way :). Can anyone tell me how to do it? > > You need to create a subclass of PluggableListMorph and LazyListMorph, > override #listMorphClass in the PluggableListMorph to return the lazy > morph class, and override the method #display:atRow:on: in the > LazyListMorph subclass to customize the low-level drawing of the list > item. > > As you imagined all pretty simple and strait-forward, have a look at > the OB-Morphic for an example :-) > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Sept. 11, 2009

Re: [Pharo-project] icons in pluggablelistmorph

by Tudor Girba

Hi Stef, The MorphTreeMorph widget of Alain follows a different design and already provides a straightforward way to deal with icons. I already use it for displaying trees in Glamour. But, that tree widget appears to be significantly slower for displaying simple lists. That is why I want to try with PluggableListMorph to see what can be done and with what performance. Cheers, Doru On 11 Sep 2009, at 20:40, StÃ©phane Ducasse wrote: > doru > > do you also need to do what lukas suggested with the tree of alain? > Is there a reason not to use it? > > Stef > On Sep 11, 2009, at 8:13 PM, Tudor Girba wrote: > >> Hi, >> >> I would like to specify an icon in a PluggableListMorph, but I cannot >> find my way :). Can anyone tell me how to do it? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Being happy is a matter of choice."

Sept. 11, 2009

Re: [Pharo-project] An important infrastructural question

by Dale Henrichs

GemStone (GLASS) will be writing and reading "old-style" mcz files for the foreseeable future, so backward compatibility is important. Dale ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | > Â Â Â Â Â Â Â Â - idea: we keep the * notation but we hook into the | tools to | > Â Â Â Â Â Â Â Â create real package. In particular the user could | either explicitly | > add a method extension | > Â Â Â Â Â Â Â Â to a package or use the* notation. The end result | should be the star | > notation in the cat | > Â Â Â Â Â Â Â Â and the use of a real package in the background. | | It would be nice if old packages could be imported and new ones | merged | and exported without problems. If a package is named "Foo", then its | categories would be represented in Monticello as | "Foo-OriginalCategoryName" and its protocols as | "*foo-OriginalProtocolName". This would allow full compatibility. | | > Â Â Â Â platform could be a problem. So lukas do you if VW uses the | * | > convention, I imagine at least when | > Â Â Â Â saving code? | | Yes, they use the same convention. Categories are not really visible | in VW, but they are the same as on the Pharo side. The package name | could actually be cropped from the protocol, but they strangely don't | do that and still display the *. | | Cheers, | Lukas | | | -- | Lukas Renggli | http://www.lukas-renggli.ch | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 11, 2009

Re: [Pharo-project] May be some problems with MC history

by Lukas Renggli

>> I don't understand what this has to do with change-sets? > > there is a menu item: 'add to changeset' and I wanted to generate a cs > for each of the commit > because I wanted to be able to reload the work in another image to test. Sorry, never used (or even encountered) that menu item before. > So thanks lukas. No problem ;-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2009

Re: [Pharo-project] An important infrastructural question

by Lukas Renggli

> Â Â Â Â Â Â Â Â - idea: we keep the * notation but we hook into the tools to > Â Â Â Â Â Â Â Â create real package. In particular the user could either explicitly > add a method extension > Â Â Â Â Â Â Â Â to a package or use the* notation. The end result should be the star > notation in the cat > Â Â Â Â Â Â Â Â and the use of a real package in the background. It would be nice if old packages could be imported and new ones merged and exported without problems. If a package is named "Foo", then its categories would be represented in Monticello as "Foo-OriginalCategoryName" and its protocols as "*foo-OriginalProtocolName". This would allow full compatibility. > Â Â Â Â platform could be a problem. So lukas do you if VW uses the * > convention, I imagine at least when > Â Â Â Â saving code? Yes, they use the same convention. Categories are not really visible in VW, but they are the same as on the Pharo side. The package name could actually be cropped from the protocol, but they strangely don't do that and still display the *. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 11, 2009

Re: [Pharo-project] May be some problems with MC history

by StÃ©phane Ducasse

>> a couple of bugs when understanding the history based merge (ugly) > > It is not a merge operation, as I said in my mail. You are merely > applying the changes representing a delta between two versions > manually. That's all, no magic involved. Yes I know, I did not mean merging. Sorry for the bad working, >> - adding the new method to a cs does not work if you did not >> install >> the code before (ok) >> - class definition are not added (yeah) in the changeset. >> Really cool! > > I don't understand what this has to do with change-sets? there is a menu item: 'add to changeset' and I wanted to generate a cs for each of the commit because I wanted to be able to reload the work in another image to test. And not load and fuck up and restart kind of scenario. > Class definitions are part of the patch that is calculated by > Monticello. probably but when you use add to changesets they don't. > My guess is that the class didn't change for the delta you > calculated. Yes this is what I discovered see below. Now I really understand the limits of the functionality. > To illustrate, in the example above the changes between > b.1 and b.2 don't show a class change that happened between a.1 and > b.1, even if the delta depends on it. > > I use what I described all the time, it is maybe a bit tricky, but > works really well. I wanted to know if I can trust this functionality. So I did the following experiment and I learned a lot and now I deeply understanding what you mean :) I took latest pharo ScriptLoader new addExtraRepositories then you open the trunk repository and browse the monticello package I checked the changes made in ar 321, did not see an instance variable called methodAdditions nor the initialize method modification. The previous version of initialize was made in 2007. I compare the history between md.308 july 2006 and rkrk.320 there I saw that the initialize methods was added. I added the 3.10 repository and I found that the method initialize was added in rej.309 in 310. So now I understand and it would be nice to have a functionality to now when a change occurred. So now I can use the history and yes we should really be cautious. I wrote these emails so that other people can learn from it. So thanks lukas. Stef PS: L'idee de l'experience ne remplace pas l'experience So I'm happy I know more now :)

Sept. 11, 2009

[Pharo-project] Pavel? ChangeSorter vs ChangesOrganizer

by StÃ©phane Ducasse

Hi Pavel I have the impression that MCPackageLoader>>useChangeSetNamed: baseName during: aBlock "Use the named change set, or create one with the given name." | changeHolder oldChanges newChanges | changeHolder := (ChangeSet respondsTo: #newChanges:) ifTrue: [ChangeSet] ifFalse: [Smalltalk]. oldChanges := (ChangeSet respondsTo: #current) ifTrue: [ChangeSet current] ifFalse: [Smalltalk changes]. newChanges := (ChangeSorter changeSetNamed: baseName) ifNil: [ ChangeSet new name: baseName ]. changeHolder newChanges: newChanges. [aBlock value] ensure: [changeHolder newChanges: oldChanges]. should use Changes MCPackageLoader>>useChangeSetNamed: baseName during: aBlock "Use the named change set, or create one with the given name." | changeHolder oldChanges newChanges | changeHolder := (ChangeSet respondsTo: #newChanges:) ifTrue: [ChangeSet] ifFalse: [Smalltalk]. oldChanges := (ChangeSet respondsTo: #current) ifTrue: [ChangeSet current] ifFalse: [Smalltalk changes]. newChanges := (ChangesOrganizer changeSetNamed: baseName) ifNil: [ ChangeSet new name: baseName ]. changeHolder newChanges: newChanges. [aBlock value] ensure: [changeHolder newChanges: oldChanges]. It would be coherent not to really on UI (changeSorter) but on the domain objects (changeOrganizer). http://bugs.squeak.org/view.php?id= 4825 Stef

Sept. 11, 2009

[Pharo-project] An important infrastructural question

by StÃ©phane Ducasse

HI guys With simon we restarted to code on the new package to substitute packageInfo. Now we have a nice package class which works well (one little bug to fix) and a lot of cool tests. I believe that this was the easy part now we will have to think how to have a migration path and about the possible options. We want your feedback on the following points. Currently PackageOrganizer is not really used or half way and the responsibility are split with packageinfo ending in the kind of mess. We suggest to either use it as a factory and package registry or to remove it. The package manager class (either packageOrganizer or Package class side) should really be responsible to create, query, manage package and emit event. Since packageOrganizer is not really used may be this is easier to move its behavior to PackageInfo (and later Package) class side. events? we think that PackageOrganizer/Package should emit events so that other tools can register. Now the question is how this interact with systemNotification mutating from PackageInfo we could write a script that convert all package info (BTW full of crap) into our package: the question is then what to do with the code that we will load later and relied on * - idea: we keep the * notation but we hook into the tools to create real package. In particular the user could either explicitly add a method extension to a package or use the* notation. The end result should be the star notation in the cat and the use of a real package in the background. - fileout (MC). Similarly we could get rid of the convention at the cat level when fileouting a package. It would work at the package level but fileouting a class would break since the markers would be lost. Also porting code to Squeak or other MC based platform could be a problem. So lukas do you if VW uses the * convention, I imagine at least when saving code? So let us know what you think. Stef

Sept. 11, 2009

Re: [Pharo-project] icons in pluggablelistmorph

by StÃ©phane Ducasse

doru do you also need to do what lukas suggested with the tree of alain? Is there a reason not to use it? Stef On Sep 11, 2009, at 8:13 PM, Tudor Girba wrote: > Hi, > > I would like to specify an icon in a PluggableListMorph, but I cannot > find my way :). Can anyone tell me how to do it? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of > problem understanding." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 11, 2009

Re: [Pharo-project] BrowserEnvironment is broken?

by StÃ©phane Ducasse

If I would be red each time I do a mistake.... Stef On Sep 11, 2009, at 8:16 PM, Oscar Nierstrasz wrote: > > Boy, is my face red now! > > Thanks!!! This was driving me crazy. > > - on > > On Sep 11, 2009, at 15:51, Henrik Johansen wrote: > >> Remove your first cascade, and it works. >> I'm not sure how it worked back in July, but now selectMethods: >> doesn't >> modify the current environment, it return a new Environment on the >> methods. >> So your code is telling the Browser with the class as env to set its >> label and open, not the Browser with the methods as env. >> >> ((BrowserEnvironment new forClasses: (Boolean withAllSubclasses)) >> selectMethods: [:method | method sendsToSuper ]) >> label: 'super sends'; >> open. >> works like you expect. >> >> Cheers, >> Henry >> >> >> Oscar Nierstrasz skrev: >>> Hi Folks, >>> >>> In the latest pharo-web image (pharo1.0-10440-BETAweb09.09.1), the >>> BrowserEnvironment is acting strangely: >>> >>> (BrowserEnvironment new forClasses: (Boolean withAllSubclasses)) >>> selectMethods: [:method | method sendsToSuper ]; >>> label: 'super sends'; >>> open. >>> >>> This lists a whole bunch of methods that do *not* send super, >>> including Boolean>>#&. >>> >>> If I check: >>> >>> (Boolean>>#&) sendsToSuper --> false >>> >>> So what is wrong? This worked ok back at the beginning of July ... >>> >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 11, 2009