During the sprint (or before) I would like to look at this issue. Now I'm recovering from another disc crash.
Stef On Dec 12, 2013, at 12:56 PM, Esteban Lorenzano <[email protected]> wrote: > so far icons are all packed together into an icon pack. > > for example, Pharo3Icons and FamFamIcons. > > all tools should register their icons there, as extensions of a theme. > > then, a method: > > > MyClass clas>>#icon > ^ Smalltalk ui icons iconNamed: #myIcon > > can provide enough decoupling. > > then... is in tool developers the responsibility of follow the pattern (a > pattern that is already there, no need of new stuff). > > Esteban > > > > On Thu, Dec 12, 2013 at 12:25 PM, Sebastian Sastre > <[email protected]> wrote: > >> > > > > I think the idea here is that maybe a class should have an icon. > > Independend of Nautilus.\ > > (either just icon or toolIcon). > > > > Marcus > > > > > > In a great environment you have icons and icon-sets defined by UX/UI > designers. > > If we couple too much to code we'll create a barrier for that. > > If Nautilus (or whatever other browser) wants to display icons in classes and > packages (which I found great) it should itself provide the code for that > without system intrusion/pollution for the sake of being lazy > > Idea: > > Classes: > > NautilusIconSet > HottishIcons > CoolishIcons > > > WhoeverDisplaysTheClassListItems>>iconFor: aClass > "Returns the icon for aClass or a default icon" > > ^ aNautilusIconSet > at: Integer > ifAbsent:[self defaultIcon] > >
