[Pharo-dev] Best way to access icons?

[Aliaksei Syrel]

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:
[image: Inline image 1]

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

Cheers,
Alex

Re: [Pharo-dev] Best way to access icons?

[Esteban Lorenzano]

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  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:
> 
> 
> So, what is the best practice to access icons to use in application?
> 
> Cheers,
> Alex
> 

Re: [Pharo-dev] Best way to access icons?

[Stephan Eggermont]

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.


Stephan

Re: [Pharo-dev] Best way to access icons?

[Esteban Lorenzano]

> On 04 Feb 2016, at 17:38, Stephan Eggermont  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
> 
> 
> 

Re: [Pharo-dev] Best way to access icons?

[Aliaksei Syrel]

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 
wrote:

>
> > On 04 Feb 2016, at 17:38, Stephan Eggermont  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
> >
> >
> >
>
>
>

Re: [Pharo-dev] Best way to access icons?

[Stephan Eggermont]

On 04-02-16 17:55, Esteban Lorenzano wrote:



On 04 Feb 2016, at 17:38, Stephan Eggermont  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

Re: [Pharo-dev] Best way to access icons?

[Chris Cunningham]

On Thu, Feb 4, 2016 at 7:19 AM, Aliaksei Syrel  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:
> [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
>
>

Re: [Pharo-dev] Best way to access icons?

[stepharo]

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 > 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:


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

Cheers,
Alex

Re: [Pharo-dev] Best way to access icons?

[Ben Coman]

On Fri, Feb 5, 2016 at 5:21 AM, stepharo  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  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:
> 
>
> So, what is the best practice to access icons to use in application?
>
> Cheers,
> Alex
>
>
>

Re: [Pharo-dev] Best way to access icons?

[Esteban Lorenzano]

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  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.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:
>>> 
>>> 
>>> So, what is the best practice to access icons to use in application?
>>> 
>>> Cheers,
>>> Alex
>>> 
>> 
> 

Re: [Pharo-dev] Best way to access icons?

[Esteban Lorenzano]

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  wrote:
> 
> On Fri, Feb 5, 2016 at 5:21 AM, stepharo  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  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:
>> 
>> 
>> So, what is the best practice to access icons to use in application?
>> 
>> Cheers,
>> Alex
>> 
>> 
>> 
> 

Re: [Pharo-dev] Best way to access icons?

[stepharo]

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 > 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  wrote:

Hi

For ages to access an icon we used:

Smalltalk ui icons protocolPrivateIcon


Smalltalk ui icons returns an instance of ThemeIcons.
After refactoring 
(casehttps://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:


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

Cheers,
Alex

Re: [Pharo-dev] Best way to access icons?

[Esteban Lorenzano]

> On 07 Feb 2016, at 22:08, stepharo  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 < 
>>> 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. 
>>> 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:
> 
> 
> So, what is the best practice to access icons to use in application?
> 
> Cheers,
> Alex
> 
 
>>> 
>> 
>