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

["Nick Edgar" <Nick_Edgar@xxxxxxx>]

Mika,

What you describe below is along the lines of what we would like to move 
towards in the future: all actions (and groupings) are contribued by 
action sets, including those for the workbench itself.
The limited richness of enablement expressions in XML is one limiting 
factor.

Another factor, as you also point out, is the difficulty in updating 
enablement state incrementally.  This is hard to do in general.  I think 
it would be better to update enablement state lazily.  That is, ask the 
action delegate for its enablement only when the corresponding menu item 
is about to be shown.
It's not clear how to do this for actions on the toolbar though.  One 
option would be to always update enablement for all toolbar actions after 
any action is run, and also when the workbench window is activated after 
working in some other window.  However, this could have poor performance. 
It would also not cover the case where conditions change independently of 
the user's actions.
For example, in the Debug view that shows running processes, the 
enablement for most of the toolbar actions (e.g. Resume, Suspend, and 
Remove All Terminated Launches) depends on whether the view has any 
processes, and the state of the selected one.  The state of these can 
change any time though.
Perhaps an API to say: "the enablement of action X may have changed, ask 
again" would suffice.  If the action was visible on a toolbar, then it 
would be updated immediately (or when the UI event loop next runs).  If it 
was on a menu, then it could be deferred until the menu was shown.  This 
would still require listeners on the underlying state (in this case, the 
number of processes and their state) when the state could change 
asynchronously. But for cases like Close All that depend on the number of 
open editors, no listeners would be needed.

Nick








Mika Käki <mk@xxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
07/10/02 03:18 AM
Please respond to platform-ui-dev

 
        To:     <platform-ui-dev@xxxxxxxxxxx>
        cc: 
        Subject:        RE: [platform-ui-dev] Eclipse as a platform for custom applications


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.



_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev