Eclipse Community Forums: e(fx)clipse » Important upcoming change in toolitem-enablement check

Help

Home

Home » Eclipse Projects » e(fx)clipse » Important upcoming change in toolitem-enablement check

Show: Today's Messages :: Show Polls :: Message Navigator

Important upcoming change in toolitem-enablement check [message #1387984]

Wed, 25 June 2014 21:49

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Hi,

I'm currently working on a revised enablement check story for ToolItems
- until today there was a Thread running with 400ms pulse who was call
@CanExecute all time - it worked the same way it did in Kepler upstream.

This behavior changed in Kepler and the system only does the check in
very certain situations e.g. when the active part changes, ... - but it
does not track other context variables.

Developers have to call

eventBroker.send(
UIEvents.REQUEST_ENABLEMENT_UPDATE_TOPIC,
UIEvents.ALL_ELEMENT_ID);

I think this is a bit cumbersome but anyways that's the situation if you
write SWT-e4 applications.

I'm currently evaluating different stories on how to improve the
situation in e4+JavaFX:

a) if you publish information into the context using
- @ContextValue
- ScopedObjectFactory
we will reevaluate all ToolItems

=> Disadvantage: If someone publishes information through the
IEclipseContext directly (something i always said is a bad idea!)
we miss them!
=> active context / active selection will always lead to a
reevaluation!

b) an alternate way would be to hook the IEclipseContext to track what
values are accessed when an @CanExecute is called
(IEclipseContext-RAT unfortunately does not do that!)

c) one specifies which context keys should be tracked using RAT

If you still want to have the loop enable check we'll provide you a
possibility to turn that on in addition to one of the above solutions by
starting with a special product-extension-property switch.

Tom

Report message to a moderator

Re: Important upcoming change in toolitem-enablement check [message #1388009 is a reply to message #1387984]

Wed, 25 June 2014 22:49

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

On 25.06.14 23:49, Tom Schindl wrote:
> Hi,
>
> I'm currently working on a revised enablement check story for ToolItems
> - until today there was a Thread running with 400ms pulse who was call
> @CanExecute all time - it worked the same way it did in Kepler upstream.
>
> This behavior changed in Kepler and the system only does the check in
^^^^^^
*Luna*

Tom

Report message to a moderator

Re: Important upcoming change in toolitem-enablement check [message #1388012 is a reply to message #1387984]

Wed, 25 June 2014 22:55

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

The changes are in the repo [1] - I went for a) for now!

Tom

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=438200

On 25.06.14 23:49, Tom Schindl wrote:
> Hi,
>
> I'm currently working on a revised enablement check story for ToolItems
> - until today there was a Thread running with 400ms pulse who was call
> @CanExecute all time - it worked the same way it did in Kepler upstream.
>
> This behavior changed in Kepler and the system only does the check in
> very certain situations e.g. when the active part changes, ... - but it
> does not track other context variables.
>
> Developers have to call
>
> eventBroker.send(
> UIEvents.REQUEST_ENABLEMENT_UPDATE_TOPIC,
> UIEvents.ALL_ELEMENT_ID);
>
> I think this is a bit cumbersome but anyways that's the situation if you
> write SWT-e4 applications.
>
> I'm currently evaluating different stories on how to improve the
> situation in e4+JavaFX:
>
> a) if you publish information into the context using
> - @ContextValue
> - ScopedObjectFactory
> we will reevaluate all ToolItems
>
> => Disadvantage: If someone publishes information through the
> IEclipseContext directly (something i always said is a bad idea!)
> we miss them!
> => active context / active selection will always lead to a
> reevaluation!
>
> b) an alternate way would be to hook the IEclipseContext to track what
> values are accessed when an @CanExecute is called
> (IEclipseContext-RAT unfortunately does not do that!)
>
> c) one specifies which context keys should be tracked using RAT
>
> If you still want to have the loop enable check we'll provide you a
> possibility to turn that on in addition to one of the above solutions by
> starting with a special product-extension-property switch.
>
> Tom
>

Report message to a moderator

Re: Important upcoming change in toolitem-enablement check [message #1388236 is a reply to message #1388012]

Thu, 26 June 2014 06:48

Christoph Keimel

Messages: 482
Registered: December 2010
Location: Germany

Senior Member

Hi Tom

thanks for the infos! I'm having trouble using @ContextValue with JavaFX properties. Could you please have a look at:
https://www.eclipse.org/forums/index.php/t/782084/

I have the feeling I'm missing something ...

Smile
Christoph

Report message to a moderator

Re: Important upcoming change in toolitem-enablement check [message #1388276 is a reply to message #1388236]

Thu, 26 June 2014 07:50

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Yeah i saw that post but I had no time looking into it - to me it looks
like you are *not* missing something but i need to have an in depth look.

Tom

On 26.06.14 08:48, Christoph Keimel wrote:
> Hi Tom
>
> thanks for the infos! I'm having trouble using @ContextValue with JavaFX
> properties. Could you please have a look at:
> https://www.eclipse.org/forums/index.php/t/782084/
>
> I have the feeling I'm missing something ...
>
> Smile
> Christoph

Report message to a moderator

Re: Important upcoming change in toolitem-enablement check [message #1400712 is a reply to message #1388276]

Mon, 14 July 2014 16:03

Uwe San

Messages: 119
Registered: January 2012

Senior Member

Hi Tom,

in my use case, clicking a ToolItem will open a popup menu with two menu items. Unlike in the default case, the menu stays visible when an item was clicked. This requires an enablement check for all menu items after every click on an item, not only once after the menu is shown. Is there a way to achieve this in a custom MenuItemRenderer class? I could not find a straightforward way to change the default action callbacks.

Thanks,
Uwe

Report message to a moderator

Re: Important upcoming change in toolitem-enablement check [message #1400901 is a reply to message #1400712]

Mon, 14 July 2014 22:05

Thomas Schindl

Messages: 6651
Registered: July 2009

Senior Member

Hi,

The enable/disable stuff is not implemented by the *ItemRenderer but in
the container like ToolBarRenderer, MenuRenderer, ... .

As you noted we are currently don't reapply enablement once a Menu is
shown which sounds like a over simplification - because of performance
gains - but I think we can / need to fix this in the default
implementation so I filed
https://bugs.eclipse.org/bugs/show_bug.cgi?id=439572 and as a first step
extracted the generic part from the ToolBarRenderer.

Tom

On 14.07.14 18:03, Uwe San wrote:
> Hi Tom,
>
> in my use case, clicking a ToolItem will open a popup menu with two menu
> items. Unlike in the default case, the menu stays visible when an item
> was clicked. This requires an enablement check for all menu items after
> every click on an item, not only once after the menu is shown. Is there
> a way to achieve this in a custom MenuItemRenderer class? I could not
> find a straightforward way to change the default action callbacks.
>
> Thanks,
> Uwe

Report message to a moderator