And if we are at it, the SpecDebugger still requires the EyeInspector to be the default inspector: https://pharo.fogbugz.com/f/cases/12055/The-Spec-Debugger-should-not-require... Cheers, Doru On Wed, Dec 11, 2013 at 1:15 PM, Marcus Denker <marcus.denker@inria.fr>wrote:

On 11 Dec 2013, at 11:14, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

EyeInspector should not depend on Nautilus.

icon ^ (self value iconOrThumbnailOfSize: 16) ifNil: [ self value class nautilusIcon ]

^^^^^^^^^^^^^^^^^^^^^^

https://pharo.fogbugz.com/f/cases/12392/EyeInspector-should-not-depend-on-Na...

...

Now we are trying to fix it. The question is how to dispatch. May be we should extract from Nautilus the nautilusIcon if the

eyeInspector use it.

...

I think the idea here is that maybe a class should have an icon. Independend of Nautilus.\ (either just icon or toolIcon).

Marcus

-- www.tudorgirba.com "Every thing has its own flow"

...

I think the idea here is that maybe a class should have an icon. Independend of Nautilus.\ (either just icon or toolIcon).

Yes we got the idea :) Now we faced extensions management problems with pavel so we could not fix it. We did not want to produce more mess. But this is the next thing I want to fix because we cannot explore dependencies with a broken explorer. I think that if we are real about modularity. We should really focus on it for a while in 4.0 Else if it will never happen. People just do not think about dependencies. We should have a tool that check that. Stef

...

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]

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 <estebanlm@gmail.com> 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 <sebastian@flowingconcept.com> 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]