- Pharo-dev - lists.pharo.org

Re: [Pharo-project] another slice for popups cleaning and some questions

by HernÃ¡n Morales Durand

2009/2/8 Alain Plantec <alain.plantec(a)free.fr> > Hi all, > I've uploaded another slice for popup and co cleaning > (SLICE-MorePopUpAndCustomMenuCleaning-alain_plantec.1) > - it Removes last PopUpMenu references. > - it Removes some of CustomMenu uses (wherever it is possible to replace > it with a simpler UIManager dialog). > > I've three questions: > - EmphasizedMenu is never used, can we remove it ? > - MorphicUIManager is subclassed by PSUIManager which is now the > default UIManager. Several MorphicUImanager methods are > redefined in PSUIManager. So I guess one can simply remove > MorphicUIManager versions. Is it ok to do so ? (as an example, > #chooseDirectory:from:, in MorphicUIManager, the code is using FileList > but now we have the PSUIManager version) > - last unrelated question, I've also seen that ListParagraph is never > used, can we remove it ? ListParagraph was historically used by ListView (Minimal Morphic images) and PluggableListView>>list: , and you could find initialize references in SystemDictionary, FontSet, TextStyle, Preferences and possibly others. Let me know if you need help with this issue. Cheers HernÃ¡n > > > now I am about to see how to kill MVCMenuMorph > > cheers > alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 11, 2009

Re: [Pharo-project] Workspace API

by Damien Cassou

What do you suggest? On Tue, Feb 10, 2009 at 3:49 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > http://bugs.squeak.org/view.php?id=5669 > > I requested then implemented a reasonable API for opening Workspaces on > strings and files. I now find that pharo has implemented incompatible > versions of the same. > > Workspace openContents: 'blah'. > > or > > Workspace new > contents: 'blah'; > label: 'Title'; > open. > > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 11, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > Igor Stasenko schrieb: >> 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: >>> >>>> But again, there is no excuse in doing this each time you need a tree. >>>> Thanks to system notifier we have a ways to determine when category >>>> tree needs to be rebuilt, so it can be built once and stay cached >>>> until user add/remove/rename category. >>> yes, right. Packages are cached for a long time and also their classes and extended >>> classes. And now also the class cats per package, which is a small share though. >>> But it's good to cache iy anyway. >>> >> >> Also, note, that you need only one instance of such tree in image . >> You don't have to build this tree over and over again for each browser >> window on screen :) > > In a way, yes. > But then OB would basically do what the system itself should do, namely modeling > packages. I would rather invest in a genuine package model in the system itself than > let OB build its own persistent package model. A browser should by definition browse > an existing model and not primarily create, maintain, and make persistently > accessible a system's model. This would be like a shadow model to what the system > otherwise uses, Sounds odd to me, although from a performance point of view it would > make sense. > Well, OB using own tree of meta-nodes (OBXXXXNode & subclasses) to model different data structures and they relations. Should we expect from squeak/pharo to use same model? I think no. So, even if some day we will have categories as first class objects in system, you still will need to map them to own objects. > David > > _______________________________________________ > 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.

Feb. 10, 2009

Re: [Pharo-project] {Spam?} Re: "Real" packages.

by Travis Kay

Bill Schwab wrote: > Stef, > > Re Dolphin, class categories have long been of marginal use; I'll speak for myself on that but suspect others would agree. I am a Dolphin Pro, Squeak and Pharo users, I agree. Travis > Packages are of course extremely useful. Method categories are also quite useful, and Dolphin allows multiple categories to be assigned to a given method. Dolphin mixes virtual categories (computed by rules) with static ones maintained by the user (and serialized as part of packages). > > I can easily see where OB would get quite a speed boost out of it. > > Bill > > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > > > >>>> stephane.ducasse(a)inria.fr 2/10/2009 4:41:10 PM >>> >>>> > Alexandre implemented long time ago an hybrid model where both kind of > packages could coexist > and we should probably revive it for 1.1 > > Stef > On Feb 10, 2009, at 10:28 PM, Michael van der Gulik wrote: > > >> On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch >> >>> wrote: >>> >> So if we had real packages in Pharo as first class entities, OB >> would be much faster >> and simpler to maintain. Right now, OB models packages and class >> cats itself, has to >> take the information from both the Monticello's working copy >> managers and the >> SystemOrganizer. This is a mess and a huge pain, but what can we do. >> We should really invest in bringing real packages to Pharo. >> >> >> If you want "real" packages, I've implemented them in Squeak: >> >> http://gulik.pbwiki.com/Namespaces >> http://gulik.pbwiki.com/Packages >> >> The places the code is held, including a video and a Squeak image is >> linked from here: >> http://gulik.pbwiki.com/SecureSqueak >> >> I'm not interested in Pharo, but the code is there and is released >> under the MIT license if anybody else wants it. >> >> Gulik. >> >> -- >> http://people.squeakfoundation.org/person/mikevdg >> http://gulik.pbwiki.com/ >> _______________________________________________ >> 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 > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.0.233 / Virus Database: 270.10.20/1943 - Release Date: 02/10/09 07:20:00 > >

Feb. 10, 2009

[Pharo-project] {Spam?} Re: "Real" packages.

by Bill Schwab

Stef, Re Dolphin, class categories have long been of marginal use; I'll speak for myself on that but suspect others would agree. Packages are of course extremely useful. Method categories are also quite useful, and Dolphin allows multiple categories to be assigned to a given method. Dolphin mixes virtual categories (computed by rules) with static ones maintained by the user (and serialized as part of packages). I can easily see where OB would get quite a speed boost out of it. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 2/10/2009 4:41:10 PM >>> Alexandre implemented long time ago an hybrid model where both kind of packages could coexist and we should probably revive it for 1.1 Stef On Feb 10, 2009, at 10:28 PM, Michael van der Gulik wrote: > > > On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch > > wrote: > > > So if we had real packages in Pharo as first class entities, OB > would be much faster > and simpler to maintain. Right now, OB models packages and class > cats itself, has to > take the information from both the Monticello's working copy > managers and the > SystemOrganizer. This is a mess and a huge pain, but what can we do. > We should really invest in bringing real packages to Pharo. > > > If you want "real" packages, I've implemented them in Squeak: > > http://gulik.pbwiki.com/Namespaces > http://gulik.pbwiki.com/Packages > > The places the code is held, including a video and a Squeak image is > linked from here: > http://gulik.pbwiki.com/SecureSqueak > > I'm not interested in Pharo, but the code is there and is released > under the MIT license if anybody else wants it. > > Gulik. > > -- > http://people.squeakfoundation.org/person/mikevdg > http://gulik.pbwiki.com/ > _______________________________________________ > 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

Feb. 10, 2009

Re: [Pharo-project] "Real" packages.

by StÃ©phane Ducasse

Alexandre implemented long time ago an hybrid model where both kind of packages could coexist and we should probably revive it for 1.1 Stef On Feb 10, 2009, at 10:28 PM, Michael van der Gulik wrote: > > > On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch > > wrote: > > > So if we had real packages in Pharo as first class entities, OB > would be much faster > and simpler to maintain. Right now, OB models packages and class > cats itself, has to > take the information from both the Monticello's working copy > managers and the > SystemOrganizer. This is a mess and a huge pain, but what can we do. > We should really invest in bringing real packages to Pharo. > > > If you want "real" packages, I've implemented them in Squeak: > > http://gulik.pbwiki.com/Namespaces > http://gulik.pbwiki.com/Packages > > The places the code is held, including a video and a Squeak image is > linked from here: > http://gulik.pbwiki.com/SecureSqueak > > I'm not interested in Pharo, but the code is there and is released > under the MIT license if anybody else wants it. > > Gulik. > > -- > http://people.squeakfoundation.org/person/mikevdg > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by David RÃ¶thlisberger

Igor Stasenko schrieb: > 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: >> >>> But again, there is no excuse in doing this each time you need a tree. >>> Thanks to system notifier we have a ways to determine when category >>> tree needs to be rebuilt, so it can be built once and stay cached >>> until user add/remove/rename category. >> yes, right. Packages are cached for a long time and also their classes and extended >> classes. And now also the class cats per package, which is a small share though. >> But it's good to cache iy anyway. >> > > Also, note, that you need only one instance of such tree in image . > You don't have to build this tree over and over again for each browser > window on screen :) In a way, yes. But then OB would basically do what the system itself should do, namely modeling packages. I would rather invest in a genuine package model in the system itself than let OB build its own persistent package model. A browser should by definition browse an existing model and not primarily create, maintain, and make persistently accessible a system's model. This would be like a shadow model to what the system otherwise uses, Sounds odd to me, although from a performance point of view it would make sense. David

Feb. 10, 2009

[Pharo-project] "Real" packages.

by Michael van der Gulik

On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch>wrote: > > > So if we had real packages in Pharo as first class entities, OB would be > much faster > and simpler to maintain. Right now, OB models packages and class cats > itself, has to > take the information from both the Monticello's working copy managers and > the > SystemOrganizer. This is a mess and a huge pain, but what can we do. > We should really invest in bringing real packages to Pharo. > If you want "real" packages, I've implemented them in Squeak: http://gulik.pbwiki.com/Namespaces http://gulik.pbwiki.com/Packages The places the code is held, including a video and a Squeak image is linked from here: http://gulik.pbwiki.com/SecureSqueak I'm not interested in Pharo, but the code is there and is released under the MIT license if anybody else wants it. Gulik. -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > > >> But again, there is no excuse in doing this each time you need a tree. >> Thanks to system notifier we have a ways to determine when category >> tree needs to be rebuilt, so it can be built once and stay cached >> until user add/remove/rename category. > > yes, right. Packages are cached for a long time and also their classes and extended > classes. And now also the class cats per package, which is a small share though. > But it's good to cache iy anyway. > Also, note, that you need only one instance of such tree in image . You don't have to build this tree over and over again for each browser window on screen :) > David > > _______________________________________________ > 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.

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by David RÃ¶thlisberger

> But again, there is no excuse in doing this each time you need a tree. > Thanks to system notifier we have a ways to determine when category > tree needs to be rebuilt, so it can be built once and stay cached > until user add/remove/rename category. yes, right. Packages are cached for a long time and also their classes and extended classes. And now also the class cats per package, which is a small share though. But it's good to cache iy anyway. David

Feb. 10, 2009