Hi guys

I do not have the answer but I hate such patterns

�� Smalltalk ui icons iconNamed: #protocolExtension.

To me a tools using an icon should declare the icons as a ***local*** ressources.
We could imagine that there is a IconContainer and that as a tool I declare that I want an
icons and I install it on myself.

�� | t |
�� t := Tool new.
�� ic := IconContainer for: #darkTheme.
�� t askAninnstallIcon: ic iconFor: #button.
��
Then if the IconContainer changes, then it can notify its users to ask for a new version of the icon.

�� ic broadcastNewIcon: #button

This way

�� t does not have to use a plain bad global variable and does not care about the global namespace.
�� t should only use local resources held in classVar for example.

Such Smalltalk ui icons is a dynamic global variable!

Stef

Le 4/2/16 17:00, Esteban Lorenzano a ��crit��:

Smalltalk ui icons iconNamed: #protocolExtension.

Still ugly, but I��m not happy with the idea of a selector-per-icon�� they will never be enough and well�� is like a monolithic vision.��

Not that what we have is much better, but you can consider it an iteration :)

Esteban

On 04 Feb 2016, at 16:19, Aliaksei Syrel <alex.syrel@gmail.com> wrote:

Hi

For ages to access an icon we used:

Smalltalk ui icons protocolPrivateIcon

Smalltalk ui icons��returns an instance of ThemeIcons.

After refactoring (case��https://pharo.fogbugz.com/f/cases/16651) all methods to access icon (for example��protocolPrivateIcon)��were removed.

ThemeIcons>>#doesNotUnderstand: aMessage converts message sent to iconNamed:��aMessage selector which works.

BUT we have this all over the image:
<Screen Shot 2016-02-04 at 16.13.03.png>

So, what is the best practice to access icons to use in application?

Cheers,
Alex