[Pharo-project] OB annotation icons
Does OB have any icon associated with deprecated methods?
There is no such icon at the moment. If someone sends me a gif icon denoting deprecation, I will integrate it.
I am sorry to come up again with that, but it sort of fits the context. It is absolutely evil to display anything else than if there are super (up triangle) or sub implementations (down triangle) next to method. I just lost 10 minutes, because of these agressive green arrow that mark methods calling super. I couldn't figure out why the method wasn't run as expected. Eventually I found out that I misspelled the selector name. With the icons as they were before I would have spotted that within less than a second (no yellow triangle would be shown in this case). I hate that green arrow, it is absolutely useless and totally misleading. Lukas :-( -- Lukas Renggli http://www.lukas-renggli.ch
On 22/10/2008, at 6:38 PM, Lukas Renggli wrote:
It is absolutely evil to display anything else than if there are super (up triangle) or sub implementations (down triangle) next to method. I just lost 10 minutes, because of these agressive green arrow that mark methods calling super.
Whilst I agree that the 'calls super' is worse-than-useless, having multiple annotations can be useful if they are appropriately presented: http://linkuistics.com/ftp/Stardust-TraitAnnotation-2008-10-08.png A 'deprecated' marker would be useful in my environment. Then you'd also want to find all senders of methods for which every implementation is deprecated (or maybe just some?). Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Reflecting on W.H. Auden's contemplation of 'necessary murders' in the Spanish Civil War, George Orwell wrote that such amorality was only really possible, 'if you are the kind of person who is always somewhere else when the trigger is pulled'. -- John Birmingham, "Appeasing Jakarta"
It is absolutely evil to display anything else than if there are super (up triangle) or sub implementations (down triangle) next to method. I just lost 10 minutes, because of these agressive green arrow that mark methods calling super. I couldn't figure out why the method wasn't run as expected. Eventually I found out that I misspelled the selector name. With the icons as they were before I would have spotted that within less than a second (no yellow triangle would be shown in this case). I hate that green arrow, it is absolutely useless and totally misleading.
I'm not a big defender of the super send icon, but what would certainly have helped in your use case is an icon that denotes whether you send super to a method with a different selector. Then you would have spotted this problem maybe even quicker than if it wouldn't have had any icon. David
On Wed, Oct 22, 2008 at 12:06 PM, David Roethlisberger <squeak@webcitas.ch> wrote:
I'm not a big defender of the super send icon, but what would certainly have helped in your use case is an icon that denotes whether you send super to a method with a different selector. Then you would have spotted this problem maybe even quicker than if it wouldn't have had any icon.
Is it possible to put a configuration in the preferences so one can select what icons wants to be visible in the browser ?
I'm not a big defender of the super send icon, but what would certainly have helped in your use case is an icon that denotes whether you send super to a method with a different selector. Then you would have spotted this problem maybe even quicker than if it wouldn't have had any icon.
Is it possible to put a configuration in the preferences so one can select what icons wants to be visible in the browser ?
It is possible to do of course, but I'm not a friend of adding too many preferences for this and that... On the other hand, it seems to be impossible to find a set/configuration of icons that fits everyone's need and style. So maybe it's indeed best to just let people configure the icons they want... I will look into that. David
On Wed, Oct 22, 2008 at 1:34 PM, Dan Corneanu <dan.corneanu@gmail.com> wrote:
Wouldn't be enough for deprecated methods to just use a strikethrough font style?
+1 Lukas -- Lukas Renggli http://www.lukas-renggli.ch
No please do not change the icons. No preference. We are building a visual vocabulary. Let us fix it instead. Stef On Oct 22, 2008, at 1:14 PM, David Roethlisberger wrote:
I'm not a big defender of the super send icon, but what would certainly have helped in your use case is an icon that denotes whether you send super to a method with a different selector. Then you would have spotted this problem maybe even quicker than if it wouldn't have had any icon. Is it possible to put a configuration in the preferences so one can select what icons wants to be visible in the browser ?
It is possible to do of course, but I'm not a friend of adding too many preferences for this and that... On the other hand, it seems to be impossible to find a set/ configuration of icons that fits everyone's need and style. So maybe it's indeed best to just let people configure the icons they want... I will look into that.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
hi antony can you explain the icons what the arrow up means ? and the others? Stef On Oct 22, 2008, at 10:27 AM, Antony Blakey wrote:
On 22/10/2008, at 6:38 PM, Lukas Renggli wrote:
It is absolutely evil to display anything else than if there are super (up triangle) or sub implementations (down triangle) next to method. I just lost 10 minutes, because of these agressive green arrow that mark methods calling super.
Whilst I agree that the 'calls super' is worse-than-useless, having multiple annotations can be useful if they are appropriately presented: http://linkuistics.com/ftp/Stardust-TraitAnnotation-2008-10-08.png
A 'deprecated' marker would be useful in my environment. Then you'd also want to find all senders of methods for which every implementation is deprecated (or maybe just some?).
Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787
Reflecting on W.H. Auden's contemplation of 'necessary murders' in the Spanish Civil War, George Orwell wrote that such amorality was only really possible, 'if you are the kind of person who is always somewhere else when the trigger is pulled'. -- John Birmingham, "Appeasing Jakarta"
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 23/10/2008, at 7:21 AM, Stéphane Ducasse wrote:
can you explain the icons
The left arrow, which comes in three forms - up, down and up&down, indicates declared-in-super/subclass. It is not overloaded with any other meaning. To the left of that is space for a green '+' that indicates 'is an extension', which is also used in the instance/class list. The 'x' indicates a method containing a halt. Normally, shifting the left side of the label is a bad idea because it makes scanning the list more difficult - it forces the user to explicitly read the label - but in the case of a halt that doesn't matter as much because it is both transient and operationally very significant. Except in the case of the method that looks for #halt, because it contains the symbol without actually *being* a halt method. I am considering adding a marker-method or pragma to allow you to control those few (reflective) methods that have this problem i.e. a manual semantic annotation. The right boxed forms are: comes-from-trait, is-unfulfilled-trait- requirement and is-trait-method-conflict. One of my focusses is including better support for traits in the UI. I think the comes-from- trait is too strong in relation to it's meaning. The right downwards arrow means is-abstract e.g. #subclassResponsibility. The right red star means '#needsWork or #flag:'. Those icons horizontally accumulate to the right, so multiple icons can co-exist. Note that red always means 'attention required', and how much the red stands out is in proportion to the nature of the issue. But I always pair color with a shape change to deal with color-blindness - a poor example is in VW's SUnit fail/success markers. I use an ellipsis for labels that are truncated by virtue of having icons to the right. I also have a hover mechanism that shows the full label in-place when you hover over it iff it is truncated, either with an explicit ellipsis or simply because it is too wide for the list. Also note that the column widths can be adjusted independently, and don't have to start an equal width. Some columns will always have icon spaces, some not. I did these before I gave in and bought a copy of Fireworks, so I was limited in what I could do shape wise without manually pixel painting e.g AA embosses. Anyone who's done that knows what a fiddly PITA it is. I thing a circular badge (for the trait markers) would be less jarring in general, although it's important to maintain a consistent aesthetic in that sense across the entire product, and circular forms commit you to a reduced area for the semantic payload. Furthermore there is a significant pragmatic benefit to using simple rectlinear icons that can be done well a) with simple tools and b) by many developers, because it allows contributors to produce icons for integratable components that don't look out of place. Check out the class type icons in VW for an example of how not to do it. For a system that is *meant* to be extended by the user, this is IMO an important consideration. This is very much a work in progress. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti
participants (5)
-
Antony Blakey -
Dan Corneanu -
David Roethlisberger -
Lukas Renggli -
Stéphane Ducasse