Community
Participate
Working Groups
Beside adding content to the Workbench Model via Fragments or Modell Processors i am potentially also able to do it completely programmatically by using Factories e.g in a postConstruct-Method of part. Sample: @PostConstruct private void postConstruct(MApplication application, MTrimmedWindow trimmedWindow) { // Command erzeugen MCommand exitCommand = MCommandsFactory.INSTANCE.createCommand(); exitCommand.setElementId("net.teufel.e4.helloworld.exitCommand"); exitCommand.setCommandName("ExitCommand"); application.getCommands().add(exitCommand); // Handler erzeugen MHandler exitHandler = MCommandsFactory.INSTANCE.createHandler(); exitHandler.setElementId("net.teufel.e4.helloworld.handlers.exitHandler"); exitHandler.setContributionURI("bundleclass://net.teufel.e4.helloworld.ui/net.teufel.e4.helloworld.handlers.ExitHandler"); exitHandler.setCommand(exitCommand); application.getHandlers().add(exitHandler); // Toolbar erzeugen MToolBar myToolbar = MMenuFactory.INSTANCE.createToolBar(); MHandledToolItem exitToolItem=MMenuFactory.INSTANCE.createHandledToolItem(); exitToolItem.setElementId("net.teufel.e4.helloworld.toolitems.exitToolItem"); exitToolItem.setLabel("Beenden"); exitToolItem.setIconURI("platform:/plugin/net.teufel.e4.helloworld.ui/icons/door_out.png"); exitToolItem.setCommand(exitCommand); exitToolItem.setEnabled(true); myToolbar.getChildren().add(exitToolItem); // Trimbar erzeugen und zum Fenster hinzufuegen MTrimBar myTrimBar = MBasicFactory.INSTANCE.createTrimBar(); myTrimBar.getChildren().add(myToolbar); trimmedWindow.getTrimBars().add(myTrimBar); //E4Workbench.processHierarchy(application); } My problem is the following: When creating this toolbar manually I need to call E4Workbench.processHierarchy (the last commented line in the code) manually in order to get the toolbar enabled. Otherwise it stays disabled. Is it really necessary to call processHierarchy each time when i do manual changes in the model?
You can do it also by adding exitHandler.setObject(contributionFactory.create(exitHandler.getContributionURI(),eclipseContext)); handlerService.activateHandler(exitCommand.getElementId(),exitHandler.getObject()); before application.getHandlers().add(exitHandler); where contrubutionFactory and handlerService are injected IContributionFactory and EHandlerService services. This basically is what processHierarchy does but it does it recursively for all MHandlerContainer - s.
(In reply to comment #0) > My problem is the following: When creating this toolbar manually I need to call > E4Workbench.processHierarchy (the last commented line in the code) manually in > order to get the toolbar enabled. Otherwise it stays disabled. Is it really > necessary to call processHierarchy each time when i do manual changes in the > model? There currently isn't a listener registered for the handlers. There should be one similar to org.eclipse.e4.ui.internal.workbench.addons.CommandProcessingAddon that can react to MContext's coming and going and to handlers being added and removed. PW
Created attachment 213867 [details] Handler processing addon proposal
Created attachment 213868 [details] Minor correction
(In reply to comment #2) >There should be > one similar to > org.eclipse.e4.ui.internal.workbench.addons.CommandProcessingAddon that can > react to MContext's coming and going and to handlers being added and removed. > > PW Paul can you review this patch as a handler processor? Also as far as I saw if you move the handling of the handlers to this add-on the processHierarchy method becomes obsolete.
Thanx for the patch Sopot. I think there is a little more to it that that. On startup, you would process any handlers for an MHandlerContainer that had its IEclipseContext set. Then register the listeners. On handler add or remove, you would do nothing if the IEclipseContext was not set. When an IEclipseContext *is* set, you would do the MHandlerContainer processing for that object (and after that depend on the handler add or remove). Then you need to find all the places where we use the CommandProcessingAddon and add the handler processing add on after it. PW
> On startup, you would process any handlers for an MHandlerContainer that had > its IEclipseContext set. Then register the listeners. Ok > On handler add or remove, you would do nothing if the IEclipseContext was not > set. > > When an IEclipseContext *is* set, you would do the MHandlerContainer processing > for that object (and after that depend on the handler add or remove). To have the IEC of an MHC set is the same as saying ((MContext) handlerContainer).getContext()!=null ? > Then you need to find all the places where we use the CommandProcessingAddon > and add the handler processing add on after it. Ok Thanks Sopot
Created attachment 213943 [details] Handler with some additions
I made some modifications regarding the proposed code of the handler. First the initial processing and a prototype of context event handling. I tested by commenting out all (just in platform.ui and platform.runtime) the calls to E4Workbench.processHierarchy and so far so good. I'm not sure of the case when the IEC of an instance of MHC is "unset". What will be the TYPE and NEW_VALUE tags of the event? I need some assistance there.
*** Bug 331580 has been marked as a duplicate of this bug. ***
Created attachment 219843 [details] Patch removing E4Workbench.processHierarchy altogether. Patch does the following: 1-Creates the addon 2-Removes E4Workbench.processHierarchy method and all call references (in platform.ui repo) 3-Adds the handler to LegacyIde.e4xmi,and to all examples found in the repo.
*** Bug 316135 has been marked as a duplicate of this bug. ***
Note to self: if this gets in I have to update the e4 repo too.
I am adding to the menu dynamically like this but the call to E4WorkBench does not present the menu. Only after I restart is the menu there. IConfigurationElement[] elements = registry .getConfigurationElementsFor("org.eclipse.e4.ui.css.swt.theme"); MMenu menu = MMenuFactory.INSTANCE.createMenu(); menu.setLabel("Themes"); menu.setElementId("com.example.menu.themes"); for (IConfigurationElement element : elements) { String label = element.getAttribute("label"); System.out.println(label); if (label != null) { MDirectMenuItem item = MMenuFactory.INSTANCE .createDirectMenuItem(); item.setLabel(label); item.setElementId("com.example.menu.themes." + label); item.setContributionURI("bundleclass://com.example.e4.rcp.todo/com.example.e4.rcp.todo.handlers.ThemeHandler"); menu.getChildren().add(item); } } if (!menu.getChildren().isEmpty()) { window.getMainMenu().getChildren().add(menu); E4Workbench.processHierarchy(window); // or E4Workbench.processHierarchy(application); }
The patch looks basically good. I've pushed it to a temporary topic branch http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=pwebster/bug376254&id=3dd84641ef0bad2a0ce3b95425e285ec84b96c84 But a test is failing with the patch (there are 3 others to ignore FTM), org.eclipse.e4.ui.tests.workbench.MMenuItemTest.testElementHierarchyInContext_HandledItem() Can you give it a look? When this gets pushed, I need to remember to update eclipse.platform/platform/org.eclipse.platform/LegacyIDE.e4xmi as well. PW
@Sopot: on the UiTestAll you increasing the Java version to 1.7. I assume that is unintentional.
(In reply to comment #16) > @Sopot: on the UiTestAll you increasing the Java version to 1.7. I assume > that is unintentional. That was probably me, accidentally included the launch config when I was creating the commit for the topic branch. PW
(In reply to comment #15) > The patch looks basically good. I've pushed it to a temporary topic branch > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=pwebster/ > bug376254&id=3dd84641ef0bad2a0ce3b95425e285ec84b96c84 > > But a test is failing with the patch (there are 3 others to ignore FTM), > org.eclipse.e4.ui.tests.workbench.MMenuItemTest. > testElementHierarchyInContext_HandledItem() > > > Can you give it a look? > > When this gets pushed, I need to remember to update > eclipse.platform/platform/org.eclipse.platform/LegacyIDE.e4xmi as well. > > PW The test fails because the HandlerProcessingAddon is not instantiated at the time of the E4Workbench creation. To fix this you have to update the setUp method of the test and add ContextInjectionFactory.make(HandlerProcessingAddon.class, appContext); beside the other addons and it should work properly.
Created attachment 223321 [details] UI Tests patch Patch for the test showing what I meant in the last comment.
Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b00b923467c7a1459dac5b1b99789966863b556a Thanks Sopot. PW
Please consider https://bugs.eclipse.org/bugs/show_bug.cgi?id=394172
