eclipse: Defining your own toolbar menu in plugin.xml but using it in your view or editor's controls

The next challenge I have is how to define a toolbar menu in the plugin.xml folder, for example, to define toolbars for Sections or other widgets capable of having a toolbar (not just the main workbench page) but still pull that definition and instantiate it for my specific view or editor part such as the section. The issue where I don't see how it works is if I define it in the plugin.xml how to do I ensure that when the toolbar needs to be created from that XML specification, that it has the right parent is used such as my Section object in an editor.

The standard menu examples (eclipse 3.3) all seem to assume that it is the main workbench window page that has the toolbars and menus, except perhaps those view specific popup menus and such. Like the popup menus, I need to ensure that the right parent is used to create the toolbar.

The key to the story is the IMenuService which is accessible off the workbench (not the window). The menu service off the workbench


IMenuService service = (IMenuService) PlatformUI.getWorkbench().getService(IMenuService.class);


allows you to 2 things. Add a contribution manager factory (this type of factory populates contribution managers--one type of contribution manager is a toolbar contribution manager) and populate a contribution manager. A contribution manager sits on top of a raw SWT toolbar or menu widget and manages the order and other attributes of toolbar or menu buttons. It is like a viewer for a table or combo widget that makes SWT easier to use at the jface level.

The contribution manager factories are managed by the menu service based on URI--string paths that point to specific menu ids, etc. Hence, if you define some app-specific toolbar in your plugin.xml, then access the service, you will be able to populate a contribution manager (that fronts a toolbar) once you access the proper menu service. In your editor or view, merely define a contribution manager (such as a toolbar contribution manager) then "populate" this contribution manager by accessing the menu service from the workbench. The contribution manager can create the actual toolbar you want with the proper parent using the createControl() method. In this scenario, you do not nede to define your contribution manager factory since the default one that is used, the one that reads your plugin.xml, works fine here.

Once you have created your toolbar, you can define your handlers to be active when than editor element (like the Section) is selected and other criteria you define. I recommend that the handlers be defined in the controller class for your view or editor and handle enablement based on your presentation model or domain model in some way. If the toolbar has commands that operate at the workspace level, you can define your handlers as you normally do in the plugin.xml directly, but for smaller viewers that are highly specific, the locally defined and enabled handler gives you more control over its state more easily.

Here's the definition you can use in your plugin.xml, notice that I define a few additions points so you can add more icons:


<menucontribution locationURI="toolbar:yourapp.toolbarX">
             <command commandid="yourapp.newObject" >
             <separator name="additions1" visible="true" >
             <command commandid="org.eclipse.ui.edit.cut" >
             <command commandid="org.eclipse.ui.edit.copy" >
             <command commandid="org.eclipse.ui.edit.paste" >
             <separator name="additions2" visible="true" >
             <command commandid="org.eclipse.ui.edit.delete" >
             <separator name="additions3" visible="true" >
</menucontribution>



Then you just need the following code to access it somewhere in the class that creates your view:


protected void createToolBarManager(Composite p) {
       toolbar = new ToolBarManager(SWT.FLAT);
       getMenuService().populateContributionManager(toolbar, "toolbar:yourapp.toolbarX");
       toolbar.createControl(p);



PW on the eclipse team pointed out that you have to release the contributions after in the dispose() call for your view.


protected IMenuService getMenuService() {
    final IMenuService service = (IMenuService) PlatformUI.getWorkbench()
               .getService(IMenuService.class);
    return service;
}


public void dispose() {
   getMenuService().releaseContributions(toolbar);
}

Comments

Post a Comment

Popular posts from this blog

quick note on scala.js, react hooks, monix, auth

quick note on scala.js, react hooks, monix, auth Reactjs hooks finally came out of preview in a recent version of React. scalajs-reaction has had support for hooks since they were in preview. React hooks seem like the hot new thing but for me the question is, do hooks help improve your code by improving maintainability, time to market, TCO, etc.? Let’s take a look using authentication as an example and employ monix , a reactive observable framework that also builds on cats . We will assume we are building a SPA. Does it improve your code and make your application & development experience better? Auth Auth processing can be complex. Many react auth examples you find in blogs like to show how to use “react-routing” and “auth” as a switch that determines which routes are protected or unprotected. Protected routes show application specific data. Unprotected routes show login content . Based on storing a “User” object in the browser session/local storage, th...
Read more

attributes with react and typescript.md

If you use typescript with react you may wonder what the right signature is for your “properties” interface. Obviously, your component will have few to many specific properties that reflect your domain. However, you may wish to also provide for the ability to add other attributes, such as those valid for a div property. In other words, you want to extend your props interface with that of the properties from a div element. How do you do that? There are really two issues: How do you extend your props interfaces How do you filter the props once you receive them to just those that apply. Extend Your Prop Interface or Use Sum Types It’s not uncommon to see interface Props { className ? : string yourProp ? : number } with the idea of using it in class MyComponent extends React.Component<Props, any> somewhere. If your component will have an outer div, you may also pass in a react element so that its configurable. But let’s say your outer element is a div and you wan...
Read more

zio environment and modules pattern: zio, scala.js, react, query management

zio environment and modules pattern: zio, scala.js, react, query management This blog covers a zio-based fetch design for scala.js, react web applications. It heavily uses the zio “environment” feature to help motivate a point of view on the modules pattern in effect systems. At the end, I summarize some thoughts on ergonomics and complexity. This blog assumes a basic knowledge of zio and react. scala.js is just like scala so you mostly already know scala.js. This blog is a follow-on to previous blogs: https://appddeevvmeanderings.blogspot.com/2019/10/scalajs-react-fetcher-hook_48.html and https://appddeevvmeanderings.blogspot.com/2019/11/scalajs-and-react-suspense.html . I have been keeping an eye on and culling ideas from typscript/javascript fetching libraries that address query management concerns. The formulation below incorporates some of those concerns but does not try to comprehensively duplicate well established javascript libraries. I only care about ...
Read more