- Pharo-dev - lists.pharo.org

[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

[Pharo-project] about preparing the first release
by StÃ©phane Ducasse Sept. 25, 2008

Sept. 25, 2008

Hi guys I will work using the pinesoft etoy removal package. But it can take time to do that carefully since etoy put its fingers everywhere. Now I would really like that we define a date for the first release. I would really like to have something for maximum end of october. What about you? Stef

3 4

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

Sept. 24, 2008

Stef, Given a willingness to slip (either date or feature list) if the system is unstable, a deadline is great. 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 09/24/08 4:08 PM >>> Hi guys I will work using the pinesoft etoy removal package. But it can take time to do that carefully since etoy put its fingers everywhere. Now I would really like that we define a date for the first release. I would really like to have something for maximum end of october. What about you? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] Re: Re: Re: Re: [ANN] Demo with both Truetype+Polymorph
by Bill Schwab Sept. 24, 2008

Sept. 24, 2008

It includes a Linux VM with the shutdown prompt fix - MUCH appreciated, not to mention the packages that were the point of demo :) 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 09/24/08 3:57 PM >>> thanks for the report. I guess that marcus will look into that. I do not know how he made the one click precisely. Stef

1 0

Sept. 24, 2008

I removed ComponentLikeModel. Tomorrow morning we will applied our tools on pharo and start to fix package cycles. Stef going to bed :)

1 0