Re: [Pharo-dev] About icon: and iconNamed:

Oct. 13, 2016

      Also look at #systemIcon method which define icon of class in browser.
All implementors dublicate "Smalltalk ui icons iconNamed: #myIconName".

Should we change it to #systemIconName?

Also think about remote browser which also wants to show icons over
classes. With icon name it is not problem to transfer it together with
class. With Form it is of course much expensive.

2016-10-13 14:45 GMT+02:00 stepharo <stepharo@free.fr>:
...
So I'm trying to think ;)
menuOn: aBuilder
    "Specify the menu used when writing text."
    <contextMenu>
    <RubLineNumberMenu>
    (aBuilder item: #'Find...' translated)
        keyText: 'f';
        selector: #find;
        icon: (Smalltalk ui icons iconNamed: #smallFindIcon)
====>
menuOn: aBuilder
    "Specify the menu used when writing text."
    <contextMenu>
    <RubLineNumberMenu>
    (aBuilder item: #'Find...' translated)
        keyText: 'f';
        selector: #find;
        icon: #smallFindIcon
Now I do not really like to have a symbol or an icon.
icon: aSymbol
aSymbol asIcon but we could have the provider
So for now I will finish the effort.
have
icon: anIcon and
iconNamed:
Stef
On Oct 13, 2016, at 1:03 PM, stepharo <stepharo@free.fr> wrote:
Thanks!
Just a question: How about adding an extension
Symbol>>asIcon
^ â¦ look up the icon
Form>>asIcon
^ self
what if you want to have side by side two different themes to compare the
best icons
choices?
This is a valid concern, but I do not understand how this would work if
the only thing you pass in iconName: is just one symbol:
act: aBlock iconName: *aSymbol* entitled: aString
So there needs to be a lookup. This lookup will depend on the current icon
theme. So, you could open on window with one theme, switch the theme and
then open another window. Or did I misunderstand something?
My idea was that we leave the public API of Glamour to be:
act: aBlock icon: *aSymbolOrForm* entitled: aString
and then if you want to play with things, you can also explicitly pass one
icon or another (beside relying on the default lookup behavior).
What do you think?
Doru
In this way we do not have to change the external interface, and only the
internal implementation has to send an âasIconâ before using it?
Cheers,
Doru
On Oct 12, 2016, at 10:33 PM, stepharo <stepharo@free.fr> wrote:
I'm adding
act: aBlock iconName: aSymbol entitled: aString
   self act: aBlock icon: (self iconNamed: aSymbol) entitled: aString
and
act: aBlock iconName: aSymbol on: aCharacter entitled: aString
   self act: aBlock icon: (self iconNamed: aSymbol) on: aCharacter
entitled: aString
and others ....
--
www.tudorgirba.com
www.feenk.com
"Every thing has its own flow."
--
www.tudorgirba.com
www.feenk.com
"We are all great at making mistakes."

Re: [Pharo-dev] About icon: and iconNamed:

Denis Kudriashov