Hi Lukas,
- 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. ;)
- 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.
ok, I agree here.
- 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 name of an extension method is normally not in italic, only if you are browsing
it directly in the package, and then only if it's an extension of this package.
Furthermore, you don't see to which protocol a method belongs when browsing all
methods of a class (I do that often...). Hence this icon quickly provides important
information that you otherwise have to access with several clicks.
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.
This would greatly improve the interface. The browser starts to be
really messy.
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.
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.
Cheers,
David
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
