This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 203556 - No annotation for position of menus/toolbars
Summary: No annotation for position of menus/toolbars
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Actions (show other bugs)
Version: 7.0
Hardware: PC All
: P2 normal with 4 votes (vote)
Assignee: Jan Peska
Depends on:
Reported: 2011-10-11 22:50 UTC by Geertjan Wielenga
Modified: 2013-05-30 14:03 UTC (History)
2 users (show)

See Also:
Exception Reporter:

Proposal (9.29 KB, patch)
2011-10-24 04:50 UTC, elotter
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Geertjan Wielenga 2011-10-11 22:50:07 UTC
Though the position of a menu item and a toolbar button can be set via annotation within its menu or toolbar... there's no way to set the position of a menu or toolbar relative to other menus or toolbars. Not sure what the solution could be, either. But maybe a new "@containerPosition" annotation within "@ActionReference"?
Comment 1 elotter 2011-10-12 10:29:56 UTC
Perhaps it is not needed to be added to @ActionReference, as (for example), the position of a new main menu called "Data" (say) shouldn't be influenced by individuals adding actions to that menu. What I mean is that it should not the responsibility of people adding actions to the Data menu to decide where the Data menu itself should be.

A possible layer-generating annotation could be

@FolderPosition(path="Menu/Data", position=1000) 

that generates

    <folder name="Menu">
        <folder name="Data">
            <attr name="position" intvalue="1000"/>
Comment 2 Jaroslav Tulach 2011-10-12 13:09:55 UTC
It would be better to not reveal that there is a layer behind all the annotations if possible. For example we could have:

@MenuRegistration(name="Data", displayName="My Data", position=1000)

this would immediately mean that all the action references should go into Menu/Data folder.

Anyway, I don't have any plans to work on it, so find somebody to create a patch and go through API review.
Comment 3 elotter 2011-10-12 14:56:41 UTC
I don't think @FolderPosition's path parameter exposes the presence of the layer more than (say) @ServiceProvider's path parameter - is it the annotation name that can be chosen better?

Also, my variation of the proposal is meant to be more general than just for menus or toolbars - it is intended as a way to reposition underlying folder positions in the layer (*), so it could (and perhaps should?) stand independently of the action annotations. I'm sure there are other use cases that could benefit from being able to reorder purely using annotations.

This is therefore intended as a standalone annotation, perhaps on similar to OptionsPanelController.ContainerRegistration .

(*) JT: As you say, we would like to reorder folders in the layer, without choosing a name that would be too tightly coupled to the layer.
Comment 4 elotter 2011-10-24 04:50:45 UTC
Created attachment 112355 [details]

Adds 2 files to openide.awt - the @MenuRegistration annotation, as well as its annotation processor, .
Comment 5 elotter 2011-10-24 04:51:30 UTC
(In reply to comment #4)
> Created an attachment (id=112355) [details]
> Proposal
> Adds 2 files to openide.awt - the @MenuRegistration annotation, as well as its
> annotation processor, .

Here is a simplified version, for menus only. It does not have any effect on @ActionRegistration registrations, as this is intended as (for the most part) just a menu reordering. 

In this proposal, we would have

@MenuRegistration(location={"Data","SubMenu"}, displayName="My Data", position=1000)


   <folder name="Menu">
       <folder name="Data">
          <folder name="SubMenu">
             <attr name="displayName" stringvalue="My Data"/>
             <attr name="position" intvalue="1000"/>

While the annotation is supported at package, type, method and field level, it is for the most part envisaged as to be used at the package level as typically @ActionReferences usage will refer to action registration in various different menus/toolbars/... .
Comment 6 markiewb 2012-09-22 22:50:16 UTC
An intermediate workaround is documented at