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 <steph...@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 <steph...@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 <steph...@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." > > > > > > > > > >
