- Pharo-dev - lists.pharo.org

[Pharo-project] Interesting news
by Bill Schwab Sept. 26, 2008

Sept. 26, 2008

Hello all, Have a look at: http://www.object-arts.com/content/news/excitingNews.html Object Arts and Lesser Software are collaborating on a new version of Dolphin. They are still sticking to the Windows-only angle, which I find disappointing. However, even if they hold to that, we are better off keeping and enhancing what I consider to be the best development environment I have ever used. 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

1 0

[Pharo-project] Move to package from sender and implementors list
by StÃ©phane Ducasse Sept. 26, 2008

Sept. 26, 2008

Hi guys it would be great to have the senders and implementors tools offering move to package in their menus. Stef

4 3

[Pharo-project] On Icons
by Torsten Bergmann Sept. 25, 2008

Sept. 25, 2008

Matthew suggested >Perhaps OB could use composable icons Eclipse uses a similar concept, see http://www.eclipse.org/articles/Article-Decorators/decorators.html Typical icon sizes are 16x16 and 32x32 (at least on Win32 and in most icon collections on the web). The ones in OB currently look smaller and may be too small for decorators... Bye Torsten -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

1 0

[Pharo-project] [ANN] some cleans
by StÃ©phane Ducasse Sept. 25, 2008

Sept. 25, 2008

I remove isUniClass: and clean the inspector following gary's clean. plus some leftOver related to uniclass. Stef

1 0

[Pharo-project] On Icons
by Lukas Renggli Sept. 25, 2008

Sept. 25, 2008

> OB-Enhancements version 0.203 I am horrified with all these colored icons on methods. That's worse than in the old browser with the button that had 8 different colors depending on the state of the method. - I don't want to see part of the "contents" of a method as an icon. The super-icon is useless, it only hides valuable information (for example that there is a sub-implementation). If I want to know if a method calls super (and when) I need to look at the method anyway. - The same is for abstract method icon. When browsing the protocol/interface I don't need to know that. I am more interested if any of the subclasses override it. - The same for extension methods. I see that, because it is in a different protocol and because its name is in italic (the same as with the extension classes). I don't need yet another icon. The only valuable thing for me as a developer is to know if there is a super/sub implementation of a method. And maybe if there are halts inside. The rest I can find out with one click or less, if necessary. This would greatly improve the interface. The browser starts to be really messy. Furthermore I would like to define my own icons for classes, for example Seaside component should have its own icon. So instead of hardcoding this into OB itself why not asking the class for an icon, as this is done in VW for example. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

6 27

[Pharo-project] Removing class category
by Alexandre Bergel Sept. 25, 2008

Sept. 25, 2008

Hi! I just created a package MorphicBalloon that contains the 3 classes defined in Morphic-Balloon. Here is the comment: -=-=-=-=-=-=-=-=-=-=-=-= This package contains the 3 classes that define Balloon (BalloonCanvas, BalloonRectangleMorph, MatrixTranformMorph). These three classes, are only referenced by classes defined in the class category Morphic-Support. I am not sure whether this is a good change, but it is a first step to remove class category -=-=-=-=-=-=-=-=-=-=-=-= This is an example that should raise the question about where we want to go. I feel that having class category as sub-monticellopackage is a bad thing. We should get rid of class category. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

[Pharo-project] Just for fun...
by StÃ©phane Ducasse Sept. 25, 2008

Sept. 25, 2008

Hi guys guess what... The old preferencePanelWindow is defined and created within the class Preferences of course preferencesControlPanel I will kill it. Stef

1 0

Re: [Pharo-project] about preparing the first release
by Bill Schwab Sept. 25, 2008

Sept. 25, 2008

Stability takes at least two forms: the system works AND is not going to experience violent change. Given that more of the latter is possible/expected, it might be better to start at 0.1. 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 >>> adi(a)netstyle.ch 09/25/08 5:21 AM >>> On Sep 25, 2008, at 11:12 , Damien Cassou wrote: > On Wed, Sep 24, 2008 at 10:49 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: >> I'd suggest the common major.minor[.maintenance] scheme starting >> with "1.0". > > I would not start with "1.0" because it means this is already stable > enough for anyone to rely upon. isn't this exactly the goal of the release?! Only if the shipped version is reasonably stable the people will use it... Adrian _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] About traits support in OB
by David RÃ¶thlisberger Sept. 25, 2008

Sept. 25, 2008

Hi, I'm not terribly happy with the current traits integration in OB. To browse traits used in a given class, we have this fourth switch next to instance / ? / class, called 'traits'. Clicking on it then lists in the next column all traits used in this class and the class itself. This additional column duplicates the switches instance / ? / class. For classes using traits you can see methods coming from traits in italic, methods defined but not implemented in a trait in normal font when browsing the class and in blue when browsing the trait. You also see the hierarchy of the used traits in this 'trait column'. But it's also possible to open this 'trait column' for classes that do not use any traits, this is very confusing. Also it's not nice to suddenly get five columns instead of four. My suggestions to better integrate traits is to show them below the classes using them directly in the class column, hierarchially sorted and marked either with an icon or with a colored label (eg. in blue). Like this we can get rid of this additional column and the additional 'trait' switch. The only problem I see with this change is that it might confuse people as traits are displayed along with all classes of a package/class cat in the class column, although they might not be part of neither the package/class cat nor the class hierarchy. What do you think, should I change it like this or not? Cheers, David

2 2

[Pharo-project] On Icons
by Torsten Bergmann Sept. 25, 2008

Sept. 25, 2008

David, this crashes the browser for traits. I think #browserIcon returning nil is also required in Trait/TraitDescription class. At least this works for me then. Bye Torsten -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal fÃ¼r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

4 5