Smalltalk › Pharo › Pharo Smalltalk Developers

About icon: and iconNamed:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

32 messages Options

stepharo

About icon: and iconNamed:

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

Denis Kudriashov

Re: About icon: and iconNamed:

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.

What you think?

2016-10-12 13:25 GMT+02:00 stepharo <[hidden email]>:

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

Peter Uhnak

Re: About icon: and iconNamed:

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 <[hidden email]>:
>
> > 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
> >
> >
> >
> >

Peter Uhnak

Re: About icon: and iconNamed:

Also regarding `#smallFindIcon asIcon`, there are many places where we can enter icons (e.g. Spec), so once we make a choice for Settings we should modify it there too.

Peter

On Wed, Oct 12, 2016 at 03:01:26PM +0200, Peter Uhnak wrote:

> 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 <[hidden email]>:
> >
> > > 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
> > >
> > >
> > >
> > >

Denis Kudriashov

Re: About icon: and iconNamed:

In reply to this post by Peter Uhnak

2016-10-12 15:01 GMT+02:00 Peter Uhnak <[hidden email]>:

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.

stepharo

Re: About icon: and iconNamed:

In reply to this post by Denis Kudriashov

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 <[hidden email]>:

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

stepharo

Re: About icon: and iconNamed:

In reply to this post by stepharo

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?

Le 12/10/16 à 13:25, stepharo a écrit :

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

stepharo

Re: About icon: and iconNamed:

In reply to this post by Denis Kudriashov

Le 12/10/16 à 15:25, Denis Kudriashov a écrit :

2016-10-12 15:01 GMT+02:00 Peter Uhnak <[hidden email]>:

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.

Yes so this is why we could have

menuOn: aBuilder
"Specify the menu used when writing text."
<contextMenu>
<RubLineNumberMenu>
(aBuilder item: #'Find...' translated)
keyText: 'f';
selector: #find;
icon: MyIconFactory mywonderfulIcon

or

menuOn: aBuilder
"Specify the menu used when writing text."
<contextMenu>
<RubLineNumberMenu>
(aBuilder item: #'Find...' translated)
keyText: 'f';
selector: #find;
buildIconNamed: #smallFindIcon

Denis Kudriashov

Re: About icon: and iconNamed:

In reply to this post by stepharo

2016-10-12 20:06 GMT+02:00 stepharo <[hidden email]>:

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 #iconName:?

stepharo

Re: About icon: and iconNamed:

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

2016-10-12 20:06 GMT+02:00 stepharo <[hidden email]>:

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 #iconName:?

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

stepharo

Re: About icon: and iconNamed:

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 <[hidden email]>:

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 #iconName:?

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

stepharo

Re: About icon: and iconNamed:

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

Tudor Girba-2

Re: About icon: and iconNamed:

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

philippeback

Re: About icon: and iconNamed:

In reply to this post by stepharo

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

Henrik Sperre Johansen

Re: About icon: and iconNamed:

In reply to this post by Denis Kudriashov

On 12 Oct 2016, at 8:09 , Denis Kudriashov <[hidden email]> wrote:

2016-10-12 20:06 GMT+02:00 stepharo <[hidden email]>:
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 #iconName:?

Isn't this exposing internal implementation details in the external API?

The end result is a menu or a setting displayed with the corresponding iconNamed: associated, no?

Cheers,

Henry

signature.asc (859 bytes) Download Attachment

stepharo

Re: About icon: and iconNamed:

In reply to this post by Tudor Girba-2

> 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?

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

Tudor Girba-2

Re: About icon: and iconNamed:

Hi,

On Oct 13, 2016, at 1:03 PM, stepharo <[hidden email]> 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 <[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."

stepharo

Re: About icon: and iconNamed:

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.

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

stepharo

Re: About icon: and iconNamed:

In reply to this post by Tudor Girba-2

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 pass a symbol.

icon: aSymbol

aSymbol asIcon

But we cannot plug a provider

So for now I would like to continue

Stef

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

stepharo

Re: About icon: and iconNamed:

In reply to this post by Tudor Girba-2

So I'm trying to think ;)

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 <[hidden email]> 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 <[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."