Smalltalk › Pharo › Pharo Smalltalk Developers

GLMPresentation and actions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Torsten Bergmann

GLMPresentation and actions

Hi Glamour experts,

There are methods in GLMPresentation like

#act:icon:entitled:
#act:icon:on:entitled:

adding an action but (unfortunately) these methods do not return the action itself but the presentation instead.
But the presentation itself is the receiver of the message so the sender already has access to
it anyway.

Not returning the created action makes it hard to access the action afterwards to send
additional messages to it (like #condition: or other).

One would have to implement a

#act:icon:entitled:condition:

and other flavours - ending up in a lot of method variations.

Example: in CatalogBrowser>>defineAllRepositoriesInMCBrowserButton:
I have access to the list (a presentation) and I can use #act:icon:entitled: to add an action button
but have no access to the action added afterwards.

Should we change these methods to return the action and also GLMPresentation>>#addAction:
to return the action:

addAction: anAction

^self actions addLast: anAction

This way it would be similar to a collection: if you add an element you get it in return.

IMHO this would prevent adding more and more "flavour" messages in the future. What do you
think.

Also: I would like the action buttons in CatalogBrowser to be only enabled when
an item in the list (presentation) is selected. How can I do that?
There is a #condition: for an action but that is the condition for the button
to be there. There is no updating #enabledWhen: or other.

Thanks
T.

Andrei Chis

Re: GLMPresentation and actions

Hi,

On Thu, Aug 27, 2015 at 10:08 AM, Torsten Bergmann <[hidden email]> wrote:

Hi Glamour experts,

There are methods in GLMPresentation like

#act:icon:entitled:
#act:icon:on:entitled:

adding an action but (unfortunately) these methods do not return the action itself but the presentation instead.
But the presentation itself is the receiver of the message so the sender already has access to
it anyway.

Not returning the created action makes it hard to access the action afterwards to send
additional messages to it (like #condition: or other).

One would have to implement a

#act:icon:entitled:condition:

and other flavours - ending up in a lot of method variations.

Yes, currently that is the way to do it.

Example: in CatalogBrowser>>defineAllRepositoriesInMCBrowserButton:
I have access to the list (a presentation) and I can use #act:icon:entitled: to add an action button
but have no access to the action added afterwards.

Should we change these methods to return the action and also GLMPresentation>>#addAction:
to return the action:

addAction: anAction

^self actions addLast: anAction

This way it would be similar to a collection: if you add an element you get it in return.

IMHO this would prevent adding more and more "flavour" messages in the future. What do you
think.

The entire scripting API from Glamour is based on sending multiple message sends that return

#yourself to the presentation object. Changing #addAction: would break that.

Now more or less, the current messages for adding actions to a presentation are shortcuts for common cases.

If you need to configure an action differently you could bypass this API add add it directly either

using #dynamicActions: or #addAction:

Also: I would like the action buttons in CatalogBrowser to be only enabled when
an item in the list (presentation) is selected. How can I do that?
There is a #condition: for an action but that is the condition for the button
to be there. There is no updating #enabledWhen: or other.

Currently there is no direct support for this. We usually added actions that should only be available

when a item is selected in a context menu as selectionActions.

Still having the possibility to enable/disable actions is useful so could you open a bug/feature request :)

Cheers,

Andrei

Thanks
T.