[Pharo-project] OB annotation icons
use a strikethrough font style?
+1 For icons: why not reuse some of the Eclipse icons. As far as I know they are free to use and some developers might be familiar with them [1]. Would also be good to work with small overlays/decorators as Eclipse does [2]. Bye Torsten [1] http://www.nur-scheuer.de/archives/243-Eclipse-Icons.html [2] http://www.eclipse.org/articles/Article-Decorators/decorators.html -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
For icons: why not reuse some of the Eclipse icons. As far as I know they are free to use and some developers might be familiar with them [1].
The problem discussed in this thread is kind of independent of the set of icons we use. Even with perfect icons the problem Lukas mentioned exists. The idea of the preference settings for icons is more to enable/disable the denotation of certain kind of facts (super send, sub-impl., whatever) by icons, not what concrete icon to use for what fact. This should really be fixed I think, otherwise it gets too complex. Or if people really want to use their own icons, they can always go and change those we provide. anyway, I don't particularly like the Eclipse icon set. It's nice for Eclipse, but it doesn't fit well to Squeak/Pharo IMO. I think that we should just have a very small amount of meaningful icons that are well done so that developers get used to them quickly. Most icons of Eclipse I really can't interpret, we don't want that to happen in Pharo. I will meet a designer tomorrow who might draw some cool icons for those facts we already have icons integrated, and that should do it. I think.
Would also be good to work with small overlays/decorators as Eclipse does [2].
In general yes. But in the columns of OB we don't have enough space to also add meaningful decorations to icons. Cheers, David
On 22/10/2008, at 11:37 PM, David Roethlisberger wrote:
But in the columns of OB we don't have enough space to also add meaningful decorations to icons.
The screenshot I posted was OB, and I have arbitrary space. You just need to address a particular OB flaw - the use of Text as the abstraction (?!) for an annotated presentation item that is subsequently rendered into a list. A better abstraction should be preserved from node -> filters -> list, and manifested (relative to the UI domain) only in the list renderer. I've found that to be a worthwhile OB improvement (one of many), although to fix OB cleanly results in significant breaking change, because while OB is a great prototype, like many things in Squeak, the prototype wasn't respected as such as has been used quite extensively. IMHO. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands at times of challenge and controversy. -- Martin Luther King
Hi Antony,
The screenshot I posted was OB, and I have arbitrary space.
I very much like what I see in this screenshot. ;) Any possibility to see how you do this browser?
You just need to address a particular OB flaw - the use of Text as the abstraction (?!) for an annotated presentation item that is subsequently rendered into a list.
Could you elaborate on that? I don't quite get this. How is the fact that we use text (or string) to represent labels of items to be rendered in lists related to the space usage in these lists due to icons? This annotated text is just one representation of the item, the icon is another one (kind of). So how could help us another abstraction here? although to fix OB cleanly results in significant
breaking change, because while OB is a great prototype, like many things in Squeak, the prototype wasn't respected as such as has been used quite extensively. IMHO.
Very true. David
On 23/10/2008, at 1:05 AM, David Roethlisberger wrote:
Any possibility to see how you do this browser?
It's a commercial effort, but I will explain it.
Could you elaborate on that? I don't quite get this. How is the fact that we use text (or string) to represent labels of items to be rendered in lists related to the space usage in these lists due to icons?
Because the decision about how to represent those things is taken too early - in the model in effect. This is because of the #displayString:forNode: model. The system commits to a concrete (and very limited) representation too early.
This annotated text is just one representation of the item, the icon is another one (kind of). So how could help us another abstraction here?
Rather than using strings, I use an object that represents an annotated label, which HAS a string but IS NOT a string. Filters can add/change annotations (nv-pairs) and when the list comes to render the item *the list* can decide how to render the string (which isn't styled) and the annotations. This is appropriate because the list is the first time the presentation object hits the UI. The renderer on the list can use a strategy pattern for different contexts and/or UI mechanisms. So the render can add more space and different locations for different types of things, and it can even do it dynamically e.g. adding an icon column if ANY item has a certain class of annotation - although that presumes a non-lazy implementation, which I use because I've completely re-implemented lists, scrollpanes, scrollbars etc. Furthermore the label object can carry a reference to the original model object, which makes DnD and command discovery/invocation more straightforward. I think there's too much unconsidered reuse in Squeak e.g. "Text looks like it sort of does what we want, *and it will be quick to do* - let's use that". IMO this is partly due to the 'playground' nature of Squeak, where the quality of the vision and specific goals are lost in a sea of playful expediency, and partly inherent to Smalltalk. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Borrow money from pessimists - they don't expect it back. -- Steven Wright
participants (3)
-
Antony Blakey -
David Roethlisberger -
Torsten Bergmann