Bug 160250 - Utility methods to create context menus from a custom extension point in the layer file
Utility methods to create context menus from a custom extension point in the ...
Status: NEW
Product: platform
Classification: Unclassified
Component: -- Other --
6.x
All Windows Vista
: P3 with 2 votes (vote)
: TBD
Assigned To: issues@platform
issues@platform
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-13 11:45 UTC by puce
Modified: 2009-03-13 12:49 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description puce 2009-03-13 11:45:53 UTC
Creating context menus from a custom extension point in the layer file (when "Loaders/<mime-type>/Actions" is not
suitable) is quite hard if not impossible without duplicating logic already implemented in other parts of the platform.

Often required features:
- Compatible to Node.getActions(boolean): Action[]
- Subfolders -> sub-menus (needs special Actions when returned by one-dimensional "Node.getActions(boolean): Action[]"!?)
- SystemFileSystem.localizingBundle-attribute -> localize  sub-menus
- SystemFileSystem.icon
- position-attribute
- JSeparator
- Actions
- Presenter.Menu ?
- Presenter.Popup ?
- lazy menus ?
- ... 

There should be a framework/ utility method(s) in the platform to create such menus. This should also be used from
inside the platform to reduce duplicated logic. 

Eg. while debugging I found the following classes, which do similar stuff:
org.openide.loaders.DataLdrActions
org.openide.awt.DynaMenuModel
org.openide.awt.MenuBar
org.openide.util.Utilities 
org.openide.actions.FileSystemAction
org.openide.actions.ToolsAction 

Not all implementations seem to support all of the mentioned features. This would be a good time to check if this was
intended.

The most suitable utility method I found so far is:
org.openide.util.Utilities.actionsToPopup(Action[], Lookup)

but it returns a JPopupMenu not a List<JMenuItem>, which cannot be used to recursivly create the sub-menus (eg. inside a
custom action) in a clean way.
There also doesn't seem to be a publicly available action, which creates the sub-menus.

And the menu items created by this utility method don't synchronize with the enable-property of their associated action.

Related discussions on the dev@openide.netbeans.org mailing list I've started:
http://forums.netbeans.org/topic8787.html
http://forums.netbeans.org/topic9455.html
http://forums.netbeans.org/topic9657.html
Comment 1 puce 2009-03-13 11:50:33 UTC
I tried to debug why the menu items created by org.openide.util.Utilities.actionsToPopup(Action[], Lookup) don't
synchronize with the enable-property of their associated action and as far I could see up to now the call sequence is:

Utilities.actionsToPopup(Action[], Lookup)
AWTBridge.getDefault().createPopupPresenter(action)
org.netbeans.modules.openide.awt.DefaultAWTBridge.createPopupPresenter(Action)
org.openide.awt.Actions.MenuItem (action, false)
org.openide.awt.Actions.connect(this, aAction, !useMnemonic)
org.openide.awt.Actions.MenuBridge(item, action, popup)

MenuBridge extends ButtonBridge, which extends Bridge.

Unfortunatly it seems that ButtonBridge does not set the action property
of the button.

Furthermore MenuBridge calls:

if (item instanceof Actions.MenuItem) {
// addnotify/remove notify doens't make sense for menus and
// popups.
MenuBridge.this.comp.removePropertyChangeListener(listener);
}

I don't see the reason for this. I think this could be the cause why the
item is not updated! (Though I think using the action property rather
than adding a propertyChangeListener would be the cleaner solution.)

And why is this only need if the item (JMenuItem) is an instance of
Actions.MenuItem (if it's needed at all)???


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo