RE: [platform-ui-dev] Eclipse as a platform for custom applications

[Mika Käki <mk@xxxxxxxxx>]

Hi all!

> The Eclipse Workbench is currently tailored to being a 
> development tools 
> platform, rather than a generic application framework.
> Several menu items are hardwired by the workbench (to see which ones, 
> choose Window / Close All Perspectives).

I have just tackled with exactly the same problem as I feel Eclipse is
very appealing also as a generic application framework. I asked about
the customization of the menus in eclipse.tools -newsgroup and Simon
Arsenault replied to me stating the same thing: there is currently no
way to customize certain menu items.
 
> However, it is reasonably straightforward to change these if you are 
> willing to customize the org.eclipse.ui plugin.  See the code in 
> org.eclipse.ui.internal.WorkbenchActionBuilder.
> 
> As part of our future direction, I would like to open this up 
> and have a clearer architectural division between a generic workbench 
> and the current default actions.

One solution, in my mind, could be to make it possible to supply all
menus (especially the top level menu) and actions in plugin.xml files.
This would clear up the division between generic workbench (defines only
the mechanism to insert menus and actions) and concrete applications
(define concrete menus and actions).

But removing all hardcoded menus results in one major issue: hardcoded
menus serve as a place holders for actions and menus declared by plugins
by defining default menugroups. My preliminary solution is such that
there is support in org.eclipse.ui.internal.PluginActionBuilder to
create toplevel menu groups. In this scenario, developer is able to
define the structure of the toplevel menu by using plugin definition
like:

<extension
      id="org.example.defaultactionsextension"
      name="Default Actions"
      point="org.eclipse.ui.actionSets">
   <actionSet
         label="Default Actions"
         visible="true"
         id="org.example.defaultactions">
      <!-- Create top level menu groups. Note that the order of -->
      <!-- groupMarkers define also the order for menus. This   -->
      <!-- does not have any visible results.                   -->
      <menu                           
            label="TopLevelMenu"
            path="/"
            id="org.example.mainmenu">
         <groupMarker name="file_menu_group"/>
         <groupMarker name="edit_menu_group"/>
         <groupMarker name="window_menu_group"/>
      </menu>
      <!-- Create default edit menu into edit_menu_group. -->
      <menu                           
            label="Edit"
            path="edit_menu_group"
            id="org.example.editmenu">
         <separator name="undo"/>
         <separator name="cutcopypaste"/>
         <separator name="find"/>
      </menu>
      <!-- Create default file menu into file_menu_group. -->
      <menu                           
            label="File"
            path="file_menu_group"
            id="org.example.filemenu">
         <separator name="newopen"/>
         <separator name="save"/>
         <separator name="exit"/>
      </menu>
      <!-- Add an example action to edit menu -->
      <action                         
            label="Copy"
            retarget="true"
            menubarPath="org.example.editmenu/cutcopypaste"
            id="org.example.copy_action">
      </action>
   </actionSet>
</extension>

This example is now working for me, although I have not throughly tested
it. 

One issue has risen as I have tested the solution by trying to
reimplement some of the actions defined in WorkbenchActionBuilder to be
defined in plugin.xml rather that in code. I have used
IWorkbenchWindowActionDelegate to implement these actions. Setting the
enablement state of the actions could become a problem as enablement
control accessible in plugin.xml does not seem enough for all of these
actions (e.g. CloseAllAction needs to know if there is any editor open
in current page). 

The delegate may well connect to listen appropriate components itself
and decide the state this way. However, it needs a reference to actual
action to notify UI about changes in the state. How it would get the
reference is not clear to me, one possibility is to modify/extend
IWorkbenchWindowActionDelegate interface to include the action reference
in init method (I have hacked this kind of solution to test that it
works). But yes, compability issues...

I'd be interested to hear any comments on these ideas.



	.mika.




  _______________________
  M i k a         K ä k i
  University  of  Tampere
  Computer Sciences Dept.