On Sep 23, 2008, at 10:26 AM, David Röthlisberger wrote:
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?
no this is terrible because we cannot rely on the consistency of the
information
Or one containing both information, but I guess you won't like
that. ;)
I think that this is what we should have
- 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.
I disagree there.
Browse stream and collection.
- 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.
I agree. The icon is ugly but it is important (see other mail)
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.
Yes this is important that the class get its word
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
