Community
Participate
Working Groups
Build Identifier: I20111201-2015 I develop a small (and later big) eclipse rcp application. currently i try to hide/disable the MainMenu for a special key shortcut. i got the TrimmedWindow via the ModelService and from there, i got the MainMenu. if setting this instance visible = false and/or enabled = false, doesn't work. no exception, no behavior. it just do nothing. Here the sample code: @Execute public void execute(MApplication application, EModelService service){ List<MTrimmedWindow> findElements = service.findElements(application, "myTrimmedWindow", MTrimmedWindow.class, null); findElements.get(0).getMainMenu().setVisible(false); findElements.get(0).getMainMenu().setEnabled(false); } Reproducible: Always Steps to Reproduce: 1.see code
You currently can't hide the main menu bar at all (and probably not like that). Setting an MMenu to visible=false should work for submenus however. PW
Hm at the SWT-Level this is certainly possible so I think all we need is to make the renderer smarter: Here's a pure SWT/JFace snippet to toggle menubar: package test; import org.eclipse.jface.action.Action; import org.eclipse.jface.action.MenuManager; import org.eclipse.swt.SWT; import org.eclipse.swt.events.SelectionAdapter; import org.eclipse.swt.events.SelectionEvent; import org.eclipse.swt.layout.GridLayout; import org.eclipse.swt.widgets.Button; import org.eclipse.swt.widgets.Decorations; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class Testmenu { /** * @param args */ public static void main(String[] args) { Display d = new Display(); final Shell s = new Shell(d); s.setLayout(new GridLayout()); final MenuManager mgr = new MenuManager(); MenuManager submenu = new MenuManager("Menu"); submenu.add(new Action("Test") { }); mgr.add(submenu); mgr.createMenuBar((Decorations)s); s.setMenuBar(mgr.getMenu()); Button b = new Button(s, SWT.PUSH); b.setText("Toggle"); b.addSelectionListener(new SelectionAdapter() { @Override public void widgetSelected(SelectionEvent e) { if( s.getMenuBar() == null ) { s.setMenuBar(mgr.getMenu()); } else { s.setMenuBar(null); } } }); s.open(); while( ! s.isDisposed() ) { if( ! d.readAndDispatch() ) { d.sleep(); } } d.dispose(); } }
ThomasK, are you by chance contributing menus through a MMenuContribution? There's a bug I uncovered as part of bug 359778 where the menu manager is disconnected from menus coming from MMenuContributions. You could try applying that patch and see if it makes a difference.
(In reply to comment #3) > ThomasK, are you by chance contributing menus through a MMenuContribution? > There's a bug I uncovered as part of bug 359778 where the menu manager is > disconnected from menus coming from MMenuContributions. You could try applying > that patch and see if it makes a difference. The problem is clearly seen in the renderer which doesn't handle the visible change on root menu where it has to remove the menubar from the decoration-instance.
(In reply to comment #4) > The problem is clearly seen in the renderer which doesn't handle the visible > change on root menu where it has to remove the menubar from the > decoration-instance. That's actually the exact scenario where I discovered the issue with contributed menus. I was trying to implement activities support to hide/show a top-level menu using setVisible().
(In reply to comment #5) > (In reply to comment #4) > > The problem is clearly seen in the renderer which doesn't handle the visible > > change on root menu where it has to remove the menubar from the > > decoration-instance. > > That's actually the exact scenario where I discovered the issue with > contributed menus. I was trying to implement activities support to hide/show a > top-level menu using setVisible(). I'm not sure what capabilities have to do with the Windows-Main-Menu-Bar I can't believe this has something to do with it. We are talking here about Decoration#setMenuBar() and not something like the File, ... Menu
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > The problem is clearly seen in the renderer which doesn't handle the visible > > > change on root menu where it has to remove the menubar from the > > > decoration-instance. > > > > That's actually the exact scenario where I discovered the issue with > > contributed menus. I was trying to implement activities support to hide/show a > > top-level menu using setVisible(). > > > I'm not sure what capabilities have to do with the Windows-Main-Menu-Bar I > can't believe this has something to do with it. We are talking here about > Decoration#setMenuBar() and not something like the File, ... Menu exactly
(In reply to comment #6) > I'm not sure what capabilities have to do with the Windows-Main-Menu-Bar I > can't believe this has something to do with it. We are talking here about > Decoration#setMenuBar() and not something like the File, ... Menu Oops sorry, my fault: I failed to read the original code snippet deeply enough and was interpreting the bug title "Hide a MainMenu MMenu at from a handler hat runtime" as indicating problems hiding *a* MMenu defined from the main menu.
I've facing the same problem. A possible workaround is to get the MenuManager and force an update of the modified main menu structure. MMenu mainMenu = window.getMainMenu(); org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer renderer = (MenuManagerRenderer)mainMenu.getRenderer(); mainMenu.getChildren().get(0).setVisible(true); renderer.getManager(mainMenu).update(true);
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This is a mass change to close all e4 bugs marked with "stalebug" whiteboard. If this bug is still valid, please reopen and remove the "stalebug" keyword.
Still relevant. Can also be triggered by the model spy (trigger visible true/false) which also crashes the application.
