On Wed, Oct 12, 2016 at 02:28:44PM +0200, Denis Kudriashov wrote:

Hi Stef.

It is really good idea. And it makes me think why we ask users for real icon Form and not just name?

Because ThemeIcons may not be the only place from which you draw icons, and because programming with strings doesn't scale. In any case, assuming we can easily customize the icon retrieval (with the default being Smalltalk ui icons), then I have no problems with this. Btw, there was a push to use also `#smallFindIcon asIcon`, I am not sure if this is possible in Pharo 6. (this is nice and short for standard icons, but cannot be customized, which is sometimes problem). Pharo

We could say any component which shows icons should be created with concrete ThemeIcons ("Smalltalk ui icons" by default) to retrieve actual form by name. And users should always specify icon names instead of forms.

What you think?

2016-10-12 13:25 GMT+02:00 stepharo <stepharo@free.fr>:

...

Hi glamourers and other

Hi

I'm currently enhancing the API of Settings to propose to the users to pass not an icon but an icon named so that all the clients are not force to use. See below.

Now it would be great if Glamour could do the same.

Doru and Andrei?

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; iconNamed: #smallFindIcon

Stef

2016-10-12 15:01 GMT+02:00 Peter Uhnak <i.uhnak@gmail.com>:

Because ThemeIcons may not be the only place from which you draw icons, and because programming with strings doesn't scale.

It is not programming with strings. Most users of icons (I really think all of them) are only specify name and really don't care how retrieve them.

Le 12/10/16 à 14:28, Denis Kudriashov a écrit :

Hi Stef.

It is really good idea. And it makes me think why we ask users for real icon Form and not just name?

We could say any component which shows icons should be created with concrete ThemeIcons ("Smalltalk ui icons" by default) to retrieve actual form by name. And users should always specify icon names instead of forms.

I think that tools should be parametrized with an icon provider object. Stef

What you think?

2016-10-12 13:25 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:

Hi glamourers and other

Hi

I'm currently enhancing the API of Settings to propose to the users to pass not an icon but an icon named so that all the clients are not force to use. See below.

Now it would be great if Glamour could do the same.

Doru and Andrei?

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; iconNamed: #smallFindIcon

Stef

2016-10-12 20:06 GMT+02:00 stepharo <stepharo@free.fr>:

In fact I do not really like iconNamed: as a name for a setter (for menu items and settings) May be it should be iconSelector: or buildIconNamed: because else we will confuse iconNamed: which returns an icon and iconNamed: that just sets the selector to retrieve the selector.

What do you think?

maybe #icon*Name:?*

I started to enhance GLMAction that way (GLMGenericAction new) title: 'Cut'; action: [ :aPresentation | aPresentation cut ]; iconName: #smallCutIcon; shortcut: $x; withSeparatorBefore; yourself. Le 12/10/16 à 20:33, stepharo a écrit :

Le 12/10/16 à 20:09, Denis Kudriashov a écrit :

...

2016-10-12 20:06 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:

In fact I do not really like iconNamed: as a name for a setter (for menu items and settings) May be it should be iconSelector: or buildIconNamed: because else we will confuse iconNamed: which returns an icon and iconNamed: that just sets the selector to retrieve the selector.

What do you think?

maybe #icon*Name:?*

*I see yes. I will think and change again all my fixes. Stef *

Thanks! Just a question: How about adding an extension Symbol>>asIcon ^ … look up the icon Form>>asIcon ^ self 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."

Hi,

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

Hi,

On Oct 13, 2016, at 2:16 PM, stepharo <stepharo@free.fr> 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 <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."

-- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

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 <mailto: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 <mailto: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 <http://www.tudorgirba.com> www.feenk.com

"Every thing has its own flow."

-- www.tudorgirba.com <http://www.tudorgirba.com> www.feenk.com

"We are all great at making mistakes."

On Thu, Oct 13, 2016 at 10:00 PM, Denis Kudriashov <dionisiydk@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 <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 ....

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 :

2016-10-13 17:19 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:

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

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 <dionisiydk@gmail.com>:

2016-10-13 20:27 GMT+02:00 stepharo <stepharo@free.fr>:

...

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

Done. New slice committed

2016-10-14 16:06 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:

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

And here idea to slowly remove ~Icon or ~Form suffix from icons names?

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. Phil On Wed, 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 ....

Hi,

On Oct 15, 2016, at 6:21 PM, Ben Coman <btc@openInWorld.com> wrote:

On Thu, Oct 13, 2016 at 4:12 PM, phil@highoctane.be <phil@highoctane.be> 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 <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 "If you can't say why something is relevant, it probably isn't."