On Thu, Oct 13, 2016 at 10:00 PM, Denis Kudriashov <dionisi...@gmail.com> wrote:
> 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. > Is most of that expense come from passing the same Form over a link multiple times? I vaguely wonder if content-addressable caching would help there. But anyway, wouldn't a remote browser work at a higher level that being a remote UI? and the user want to use their local theme rather than that from the remote image? cheers -ben > > > 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 .... >> >>
