Bug 431990 - [Renderer] Settting the visible property to false of the MToolbar is ignore by the renderer
Summary: [Renderer] Settting the visible property to false of the MToolbar is ignore b...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.4   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 4.5 M6   Edit
Assignee: Dirk Fauth CLA
QA Contact:
URL:
Whiteboard:
Keywords: greatfix
Depends on:
Blocks:
 
Reported: 2014-04-04 05:53 EDT by Lars Vogel CLA
Modified: 2015-03-27 16:00 EDT (History)
6 users (show)

See Also:


Attachments
Example project (14.28 KB, application/zip)
2015-02-24 15:21 EST, Lars Vogel CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Vogel CLA 2014-04-04 05:53:26 EDT
If I set the visible property of an MToolBar item to false it stays visible in the toolbar.
Comment 1 Lars Vogel CLA 2014-04-04 05:54:48 EDT
To reproduce: try via live model editor or use the modelservice to search for a MToolItem and set its visible to false.
Comment 2 Lars Vogel CLA 2014-04-06 15:24:48 EDT
I think we need to write a method similar to toBeRenderedUpdater in ToolBarManagerRenderer
Comment 3 Nobody - feel free to take it CLA 2014-04-06 17:14:15 EDT
(In reply to Lars Vogel from comment #2)
> I think we need to write a method similar to toBeRenderedUpdater in
> ToolBarManagerRenderer

I don't think that it is managed via the ToolBarManagerRenderer. For some reason this class's TBR listener has a check ' if xxx instanceof MToolBarElement' which no MToolBar satisfies. That is more meant for the MToolbarItems rather then the toolbar themselves. 

Their rendering or non rendering is managed at the PartRenderingEngine level.
Comment 4 Paul Webster CLA 2014-04-07 13:52:49 EDT
The other place you can check is the org.eclipse.e4.ui.workbench.renderers.swt.TrimBarRenderer

The MTrimBar holds all of the toolbars or tool controls for that trim

PW
Comment 5 Eric Moffatt CLA 2014-07-08 11:22:21 EDT
Note that an MToolBar *is* an MTrimBarElement...so the instanceof seems correct to me...
Comment 6 Eclipse Genie CLA 2015-02-20 17:18:51 EST
New Gerrit change created: https://git.eclipse.org/r/42344
Comment 7 Dirk Fauth CLA 2015-02-20 17:22:46 EST
Looks like the missing part in ToolBarManagerRenderer was to tell the ToolBar parent to also update.

Not sure, but from the description it sounds like this should also fix Bug 432856.
Comment 8 Lars Vogel CLA 2015-02-24 14:50:24 EST
(In reply to Dirk Fauth from comment #7)
> Looks like the missing part in ToolBarManagerRenderer was to tell the
> ToolBar parent to also update.
> 
> Not sure, but from the description it sounds like this should also fix Bug
> 432856.

Dirk, if I try this in 4.5.0.I20150203-1300 the update of the update of the toolbar works fine, even without your patch. Can you still reproduce the error with the latest release? If so, can you tell me how?
Comment 9 Dirk Fauth CLA 2015-02-24 15:09:33 EST
Hm, with the latest sources you are right, the issue related to the visible flag seems to be fixed even without my patch. That wasn't the case a few days ago.

Nevertheless, my patch seems to be necessary since it updates the toolbar layout.

Say you have a part toolbar that contains 3 items. The first is visible, the second hidden, the third visible (in my case the third shows a label). When making the second item visible, the third item is only shown partially because of the missing re-layout of the toolbar.
Comment 10 Andrey Loskutov CLA 2015-02-24 15:12:33 EST
(In reply to Dirk Fauth from comment #9)
> Hm, with the latest sources you are right, the issue related to the visible
> flag seems to be fixed even without my patch. That wasn't the case a few
> days ago.
> 
> Nevertheless, my patch seems to be necessary since it updates the toolbar
> layout.
> 
> Say you have a part toolbar that contains 3 items. The first is visible, the
> second hidden, the third visible (in my case the third shows a label). When
> making the second item visible, the third item is only shown partially
> because of the missing re-layout of the toolbar.

Can you reproduce it with CPD dialog? Disabling one of the buttons in the main toolbar seem not have any visible artifacts (at least on Linux).
Comment 11 Lars Vogel CLA 2015-02-24 15:21:00 EST
Created attachment 251074 [details]
Example project

(In reply to Dirk Fauth from comment #9)

> Say you have a part toolbar that contains 3 items. The first is visible, the
> second hidden, the third visible (in my case the third shows a label). When
> making the second item visible, the third item is only shown partially
> because of the missing re-layout of the toolbar.

I cannot reproduce. Attached an example project which uses your setup (I think). Second toolitem is invisible and if I use the model spy to make it visible, the layout looks fine for me.
Comment 12 Dirk Fauth CLA 2015-02-24 15:30:25 EST
I'll check your example.

I also uploaded an example to GitHub that I use to work on the core expression issues.

https://github.com/fipro78/e4toolbarexample

On Windows the last item in the part toolbar is only shown partially when another item is made visible. The buttons with the Eclipse icons can be used to change the visible state.

P.S. What is the CPD dialog?
Comment 13 Dirk Fauth CLA 2015-02-24 16:00:17 EST
I can reproduce the issue with your example using the Model Spy. If I dynamically set the test tool item to visible, the Quit item vanishes. If I set it to invisible again, the Quit item appears again.

With my patch, the toolbar is updated correctly.

Tested on Windows.
Comment 14 Dirk Fauth CLA 2015-02-25 02:53:56 EST
I thought about this for a while, and IMHO the situation is the following:

1. The update of the visible flag for toolbar items is reflected correctly with the current codebase. My patch has no effect on that.

2. The toolbar is not re-layouted according to the changes (at least on Windows), which is now done with my patch. 

If the hidden item is the one to the right, it doesn't become visible, so this ticket sounds like the ticket regarding the re-layout.

IMHO my patch addresses Bug 432856 and not this one, since this one seems to be already fixed with some other patches.

I don't know why you don't see this issue, but I also don't know how the part toolbar is rendered on Linux. In Windows the items are right aligned and without the re-layout of the toolbar parent (my patch), the toolbar menu grows to the right without updating the start position. So the right border moves out of the visible area.

As IMHO my patch is still necessary (but for another ticket), is it possible to connect the patch to another Bug? Should I update the commit message and the copyright header so it is connected to Bug 432856?
Comment 15 Lars Vogel CLA 2015-02-25 03:41:31 EST
(In reply to Dirk Fauth from comment #14)
> 2. The toolbar is not re-layouted according to the changes (at least on
> Windows), which is now done with my patch. 

I'm about to test your patch on Windows.
Comment 17 Lars Vogel CLA 2015-02-25 15:19:28 EST
Thanks Dirk for Windows this additional call is necessary, must be one of these SWT issuess.
Comment 18 Marc-André Laperle CLA 2015-03-27 16:00:21 EDT
I'm not sure why yet but this seems to have caused a regression in CDT, see bug 463245.