In this case traits would pollute as much as global variables (or more). Take a look at TEasilyThemed ands its users…
Esteban > On 05 Feb 2016, at 03:08, Ben Coman <b...@openinworld.com> wrote: > > On Fri, Feb 5, 2016 at 5:21 AM, stepharo <steph...@free.fr> wrote: >> 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. > > +100. At a minimum this should probably be... > self iconNamed: #protocolExtension. > > maybe supplied by a trait. > Initially this might be... > TGlobalIcons>>iconNamed: symbol > ^ Smalltalk ui icons iconNamed: symbol > > but later be replaced by... > TClassIcons>>iconNamed: symbol > ^ IconContainer at: symbol > > and the tools would know how to work with those traits, e.g. in > GTExplorer, a tab displaying the icons for a class. But IIUC traits > can't add variables, but did I hear any object can be annotated? So > could TClassIcons store a dictionary holding the icons as an > annotation on the class? But we would need some way to store such > resources with the package, in Monticello or otherwise. > > cheers -ben > >> 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.sy...@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 >> >> >> >
