> > - 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). > > What if we show the super icon only if there's no sub-implementation and > otherwise the sub-implementation icon? > Or one containing both information, but I guess you won't like that. ;)
I think that would already be better, because then the fact that there is also a sub implementation is not hidden. > And even worse, at least me I often forget to check whether a method is > implemented as an extension and tend to assume that it's a standard method > of this class, so I might use it as such, but then other people might not > have this extension loaded. With this extension icon, this doesn't happen to > me anymore. But it hides information that is totally orthogonal to packaging. I don't think these things should be mixed. > I personally don't agree with this as I can't see why this icons should > hurt any developer, in particular as you now also get an explanation label > when placing the mouse over it, so everybody should be able to quickly > understand the meaning of each icon. Of course, not everybody needs all of > those icons, but why should their presence make the browser messy? > With a little bit of "fine-tuning" (referring to your first two points), > the "mess" should be addressed well. Ok, I didn't know that. Thanks. > > 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. > > Isn't that wish somehow contradictory to what you said above? I guess I can > also see with one or two clicks whether a class is a Seaside component or > not... > But otherwise I agree, I will impl. means to let the entities decide on the > icon they will get. No, this is something else. Classes have icons according to their kind, so that I immediately see what the class is all about. For example: collections, exceptions, magnitudes, seaside components, morphs, etc. should have distinct icons. That's information that is sometimes not easily visible without clicking around. Furthermore it is important that the kind is the only icon displayed with classes, it looses its focus when other things (class comment, lint erros, ...) are displayed at the same place. So to summarize I would like to see clear responsibilities for icons and labels for classes and methods: Class Icon: Kind Class Label: Package (extensions in italic) Method Icon: Sub, super implementation (if necessary maybe the super could have a stronger color if super is called); maybe show halts with a red flag because this is something that should catch attention over everything else Method Label: Package (in italic if it is not in the same package as the class, in red if it is an override) I think that would make more sense and would be understandable without having to explain much. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
