Target changed to 3.4 which is the version currently believed to
contain the enhancements. Initial version of design document was
checked to CVS at
http://openide.netbeans.org/proposals/actions/index.html

*** Issue 10816 has been marked as a duplicate of this issue. ***

I also have a bug/RFE somewhere, assigned to dstrupl last I checked
(unfortunately I cannot find it), which deals with the clumsiness of
what happens when you right-click an Explorer node: the click changes
the node selection, and also focuses the window, which sends a message
to the window manager, which fires selection changes, which causes
actions to update in the request processor, etc., and eventually you
actually get a popup. There are many places where things can go wrong
here, as seen by many bugs "deleted the wrong thing" etc. Would be far
better to have the right-click (thus producing of a popup, NodeOp)
directly ask all actions in the context menu list, "are you enabled
with this node and this top component selected", eliminating timing
problems and dependency on JRE window focus behavior (often wrong in
the case of Unix sloppy focus at least).

Also remember #13540: make lazy actions.

First draft written, rev. 1.4 of the main document. Jesse, I hope it
addresses your comment with the "Context" paragraph.

Now it seems to be possible to define most of the actions in XML
layer, but before we suggest modules to do such change, it would be
nice to improve the localization & iconization of XML layers as
described in issue 18310.

Dafe, please take a look at the specification and implementation and
give me some comments. I feel that most of the problems have been
covered, but obviously more eyes see more things.

yes, will do.

I beleive that issue 10145 belongs here ...

I disagree, I think issue 10145 is a purely filesystems API
enhancement, unrelated to the Actions presentation layer. If a file
cannot be copied, it should not be copied either by actions nor by any
other code, right?

this issue is definitely P1 for 4.0

I did some investigation to measure potential effect of implementation
of this API. I have inserted code to do few System.gc () and print the
memory usage (Runtime.totalMemory and freeeMemory) 5s after main
window opens, I have build netbeans and tried to start it few times.

@16634 - Preparation finished, took 16301ms
Memory on heap total: 25034752 occupied: 7012808
Loaded classes: 2932

then I modified testuserdir/cache/all-layers.xml and changed the name
of Menu, Toolbars and Shortcuts folders to something else => thus
preventing the actions to be loaded. Of course the menu, toolbar and
shortcuts were empty and unassinged.

@16105 - Preparation finished, took 16013ms
Memory total: 25034752 occupied: 6400632
Loaded classes: 2796

This is in some way the most optimistic result we could achieve, but
it means 10% of memory improvement, improvement in loading classes and
also bit of startup time. The result could be even better (we are
still loading 105 of action classes - because they are referenced from
DataLoaders - I have not tried to improve this yet).

We would like to make Customizable XML infrastructure in, i.e. also
per XML Domain (Ant, DD, XMI, SVG, ...) customizable Actions.

see target milestones of individual sub issues which blocks this one
to see planned timing.

I've done some startup time measurements, namely measuring
how much time does it take to load and initialize all the startup
referenced actions from Forte EE - orion fcs (to have something big).
I've added bulk-loading code to the ModuleManager just after
enabling module classloaders and just before enabling modules.

Loading all the 130 action classes took 754ms on my machine, which is
less than 2% of the Forte EE startup time.

Those 754ms are the best startup time yield we can achive by
implementing the Commands API.

I'll attach the patch against orion's ModuleManager and the list of
the startup referenced actions for reference.

Created attachment 7015 [details]
Action preloading/measuring patch against core/modules/ModuleManager.java,v1.17 (orion_fcs branch)

Created attachment 7020 [details]
List of the SystemActions created at startup by Forte EE

Should not we also check the list of actions after browsing thru all
submenus of main window?

Assigned to new owner.

I've got a go to work on this for promo-G. Right now I am working on arch.xml:  
 
/cvs/openide/arch/arch-openide-actions.xml,v  <--  arch-openide-actions.xml 
new revision: 1.35.2.1; previous revision: 1.35 
 
To get its current version use: 
cvs co -r simplest_actions_17597 openide/arch/arch-openide-actions.xml 
 

moving opened issues from TM <= 6.1 to TM=Dev

I guess we have Actions.alwaysEnabled and TopComponent.openAction now in 6.5 and that is all we can hope for...

*** Issue 70280 has been marked as a duplicate of this issue. ***

We still need convenience implementations for a lot of things, as evidenced by the quite complex code in projectui to
display its actions, and the copy-pasted code to create dynamically visible menu items. But we may not need any
overarching plan for these.

BTW openide.awt/apichanges.xml seems to have no entry for Actions.alwaysEnabled! I guess I am thinking of c06fe6e89701.
No obvious single IZ issue corresponding to this work.

*** Issue 13540 has been marked as a duplicate of this issue. ***