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 <[email protected]
<mailto:[email protected]>> 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
<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
