About icon: and iconNamed:
Locked
12
12
Re: About icon: and iconNamed:
 
|
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 <[hidden email]>:
|
|
|
On Thu, Oct 13, 2016 at 10:00 PM, Denis Kudriashov <[hidden email]> wrote:
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
|
Re: About icon: and iconNamed:
|
|
2016-10-13 17:19 GMT+02:00 Ben Coman <[hidden email]>: 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. You see: current state requires such kind of tricks. But if users always work with icon names it will not the case completely. 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? I want to do it like this. But now classes define concrete form which should be used in UI. I would call it "no late binding for icons". |
|
|
Denis You can have a look the changes I did. There is more work to be
done but I started. https://pharo.fogbugz.com/f/cases/19201/iconNamed-part-4 What I see is that a command hierarchy is clearly missing because
SmartSuggestion, Glamour reimplement the same. Stef Le 13/10/16 à 17:30, Denis Kudriashov a
écrit :
|
|
|
In reply to this post by stepharo
Hi,
> On Oct 13, 2016, at 2:16 PM, stepharo <[hidden email]> wrote: > > >>> 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? > > The idea is that all the tools: should have an iconProvider and not a global lookup (even if the lookup can access a global) >> 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? > I would like to avoid clients to use Symbol >> asIcon it can be an internal implementation. I think I am missing something. If it is the concrete tool that should dispatch on the concrete icon set, then Glamour cannot get a symbol because Glamour does not know the tool. I am a bit under time pressure, and I likely need some days to look at this, but I will look at the code and get a better picture. Cheers, Doru >> >> 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 <[hidden email]> 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." >> >> >> >> >> >> >> >> > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow." |
Re: About icon: and iconNamed:
|
|
In reply to this post by stepharo
2016-10-13 20:27 GMT+02:00 stepharo <[hidden email]>:
Done. New slice committed |
Re: About icon: and iconNamed:
|
|
Oh!!! I just found this method: iconNamed: aSymbol ifNone: aBlock self icons at: aSymbol asSymbol ifPresent: [ :icon | ^ icon ]. "Trying the old way" ((aSymbol endsWith: 'Icon') or: [ (aSymbol endsWith: 'Form') ]) ifTrue: [ self icons at: (aSymbol allButLast: 4) asSymbol ifPresent: [ :icon | ^ icon ] ]. ^ aBlock value 2016-10-14 11:42 GMT+02:00 Denis Kudriashov <[hidden email]>:
|
|
|
yes, that was me providing a compatibility/traduction layer :)
you will find a couple more of them in the image. I call them “normalisation methods”: they are meant to translate names into something we can interpret… there is also some like that in the menu building if I remember well :P
Esteban
|
Re: About icon: and iconNamed:
|
|
2016-10-14 16:06 GMT+02:00 Esteban Lorenzano <[hidden email]>:
And here idea to slowly remove ~Icon or ~Form suffix from icons names? |
|
|
yes :) |
|
|
In reply to this post by philippeback
On Thu, Oct 13, 2016 at 4:12 PM, [hidden email] <[hidden email]> wrote:
I hesitated a while to consider this. I've come down on the side of thinking its fine, per point 2 above, you are giving it a title. cheers -ben
|
|
|
Hi,
> On Oct 15, 2016, at 6:21 PM, Ben Coman <[hidden email]> wrote: > > > > On Thu, Oct 13, 2016 at 4:12 PM, [hidden email] <[hidden email]> wrote: > Stef, > > entitled: doesn't carries the right meaning. > > entitle > ɪnˈtʌɪt(ə)l,ɛn-/ > verb > past tense: entitled; past participle: entitled > > 1. > give (someone) a legal right or a just claim to receive or do something. > "employees are normally entitled to redundancy pay" > synonyms:qualify, make eligible, authorize, sanction, allow, permit, grant, grant/give the right,give permission; More > 2. > give (something) a particular title. > "a satire entitled ‘The Rise of the Meritocracy’" > > archaic > give (someone) a specified title expressing their rank, office, or character. > "they entitled him Sultan" > synonyms:title, name, call, give the title of, label, term, designate, dub; More > > Also, why act: as a shortcut? > action:icon:label: seems nicer to me. > I am not giving any rank to my menus for sure. > > I wonder what Ben would say about this. > > > I hesitated a while to consider this. I've come down on the side of thinking its fine, per point 2 above, you are giving it a title. Also, please consider that this selector is part of a fluent API: browser show: [ :composite | composite list display: … ; act: … entitled: … ] Cheers, Doru > cheers -ben > > > > > On Wed, Oct 12, 2016 at 10:33 PM, stepharo <[hidden email]> 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 "If you can't say why something is relevant, it probably isn't." |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |