Best way to access icons?
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: [image: Inline image 1] So, what is the best practice to access icons to use in application? Cheers, Alex
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 <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
On 04 Feb 2016, at 17:38, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-02-16 17:00, Esteban Lorenzano wrote:
Smalltalk ui icons iconNamed: #protocolExtension.
Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦
Why do you see that as a problem? For me the problem is more the trainwreck.
because then you have a fixed number of icons and you cannot dynamically load more. You can create methods ad-hoc, but I do not like this in general⦠and you do not have any gain between doing: Smalltalk ui icons iconNamed: #something and doing: Smalltalk ui icons somethingIcon. ThemeIcons>>#somethingIcon ^ self iconNamed: #something So yes⦠adding a selector-per-icon is not recommended because it does not scales. Esteban
Stephan
Thanks, Esteban :) As compromise
Smalltalk ui icons iconNamed: #something
is ok for now. Cheers Alex On Thu, Feb 4, 2016 at 5:55 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 04 Feb 2016, at 17:38, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-02-16 17:00, Esteban Lorenzano wrote:
Smalltalk ui icons iconNamed: #protocolExtension.
Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦
Why do you see that as a problem? For me the problem is more the trainwreck.
because then you have a fixed number of icons and you cannot dynamically load more. You can create methods ad-hoc, but I do not like this in general⦠and you do not have any gain between doing:
Smalltalk ui icons iconNamed: #something
and doing:
Smalltalk ui icons somethingIcon.
ThemeIcons>>#somethingIcon ^ self iconNamed: #something
So yes⦠adding a selector-per-icon is not recommended because it does not scales.
Esteban
Stephan
On 04-02-16 17:55, Esteban Lorenzano wrote:
On 04 Feb 2016, at 17:38, Stephan Eggermont <stephan@stack.nl> wrote:
On 04-02-16 17:00, Esteban Lorenzano wrote:
Smalltalk ui icons iconNamed: #protocolExtension.
Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦
Why do you see that as a problem? For me the problem is more the trainwreck.
because then you have a fixed number of icons and you cannot dynamically load more.
Sorry, I don't get your point. We have extension methods, so dynamically adding more works. I usually prefer selector access over dictionary, when possible. Where is this better? Please elaborate. Stephan
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 <mailto: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 <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
On Fri, Feb 5, 2016 at 5:21 AM, stepharo <stepharo@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.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
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 <btc@openInWorld.com> wrote:
On Fri, Feb 5, 2016 at 5:21 AM, stepharo <stepharo@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.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
of course, but since we have not implemented such mechanism, we need to go one step at a time⦠first step is *not to have* everything as static as it was before. then we need to think on skins, injection, etc. Esteban
On 04 Feb 2016, at 22:21, stepharo <stepharo@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. 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 < <mailto:alex.syrel@gmail.com>alex.syrel@gmail.com <mailto: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>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
Le 5/2/16 09:21, Esteban Lorenzano a écrit :
of course, but since we have not implemented such mechanism, we need to go one step at a timeâ¦
yes but this is good to think about a good solution. :) At least this is good to know that you do not consider that as the final answer (because it sucks ;)
first step is *not to have* everything as static as it was before.
then we need to think on skins, injection, etc.
Esteban
On 04 Feb 2016, at 22:21, stepharo <stepharo@free.fr <mailto:stepharo@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. 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>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
On 07 Feb 2016, at 22:08, stepharo <stepharo@free.fr> wrote:
Le 5/2/16 09:21, Esteban Lorenzano a écrit :
of course, but since we have not implemented such mechanism, we need to go one step at a timeâ¦
yes but this is good to think about a good solution. :) At least this is good to know that you do not consider that as the final answer (because it sucks ;)
câmon⦠*you* know I also thing this solution is ugly, is just less bad than the older one⦠we have talked about this lots of times! :) Esteban
first step is *not to have* everything as static as it was before.
then we need to think on skins, injection, etc.
Esteban
On 04 Feb 2016, at 22:21, stepharo < <mailto:stepharo@free.fr>stepharo@free.fr <mailto:stepharo@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. 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 < <mailto:alex.syrel@gmail.com>alex.syrel@gmail.com <mailto: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> <https://pharo.fogbugz.com/f/cases/16651>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
On Thu, Feb 4, 2016 at 7:19 AM, 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 <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: [image: Inline image 1]
So, what is the best practice to access icons to use in application?
What if a class was created, MethodProtocol, that encapsulated this behaviour? The tools could identifiy which protocol by String (as in this method), with a 'default' or 'bucket' protocol for ones that aren't previously identified. Then, for categoryIconFor: string would either identify the methodProtocol instance and ask #icon. It might delegate however it likes - or cache it's particular icon. Just a thought. -cbc
Cheers, Alex
participants (6)
-
Aliaksei Syrel -
Ben Coman -
Chris Cunningham -
Esteban Lorenzano -
Stephan Eggermont -
stepharo