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 17597 - Rework of actions APIs
Summary: Rework of actions APIs
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Actions (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker (vote)
Assignee: Jaroslav Tulach
URL: http://openide.netbeans.org/proposals...
Keywords: API, ARCH, UMBRELLA
: 10816 13540 70280 (view as bug list)
Depends on: 15926 9679 11641 13540 13759 17527 18310 18325 18868 19485 20165 20414 21184 21281 25980 27868 30581 33025 34800
Blocks: 20532 21784 31832 31979 58412
  Show dependency tree
 
Reported: 2001-11-13 15:15 UTC by Jaroslav Tulach
Modified: 2009-08-04 16:08 UTC (History)
7 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
Action preloading/measuring patch against core/modules/ModuleManager.java,v1.17 (orion_fcs branch) (2.41 KB, patch)
2002-08-05 16:57 UTC, Petr Nejedly
Details | Diff
List of the SystemActions created at startup by Forte EE (5.91 KB, text/plain)
2002-08-06 07:25 UTC, Petr Nejedly
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2001-11-13 15:15:05 UTC
The current API needs improvements in order to work better and cleaner with new
versions of JDK and provide better support for module writers.
Comment 1 Jaroslav Tulach 2001-11-13 15:25:00 UTC
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
Comment 2 Peter Zavadsky 2001-11-13 16:44:08 UTC
*** Issue 10816 has been marked as a duplicate of this issue. ***
Comment 3 Jesse Glick 2001-11-14 09:28:10 UTC
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.
Comment 4 Jaroslav Tulach 2001-11-20 14:17:57 UTC
First draft written, rev. 1.4 of the main document. Jesse, I hope it
addresses your comment with the "Context" paragraph.
Comment 5 Jaroslav Tulach 2001-12-04 08:31:29 UTC
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.
Comment 6 Jaroslav Tulach 2002-01-07 17:14:42 UTC
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.
Comment 7 David Simonek 2002-01-07 17:31:44 UTC
yes, will do.
Comment 8 David Strupl 2002-01-28 14:18:25 UTC
I beleive that issue 10145 belongs here ...
Comment 9 Jesse Glick 2002-01-28 15:25:42 UTC
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?
Comment 10 _ ttran 2002-03-05 15:19:19 UTC
this issue is definitely P1 for 4.0
Comment 11 Jaroslav Tulach 2002-03-06 17:13:39 UTC
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).


Comment 12 _ lkramolis 2002-03-14 15:49:01 UTC
We would like to make Customizable XML infrastructure in, i.e. also
per XML Domain (Ant, DD, XMI, SVG, ...) customizable Actions.
Comment 13 David Simonek 2002-07-26 12:12:14 UTC
see target milestones of individual sub issues which blocks this one
to see planned timing.
Comment 14 Petr Nejedly 2002-08-05 16:44:34 UTC
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.
Comment 15 Petr Nejedly 2002-08-05 16:57:50 UTC
Created attachment 7015 [details]
Action preloading/measuring patch against core/modules/ModuleManager.java,v1.17 (orion_fcs branch)
Comment 16 Petr Nejedly 2002-08-06 07:25:10 UTC
Created attachment 7020 [details]
List of the SystemActions created at startup by Forte EE
Comment 17 Jaroslav Tulach 2002-08-07 12:57:39 UTC
Should not we also check the list of actions after browsing thru all
submenus of main window?
Comment 18 Jiri Rechtacek 2004-04-23 10:49:41 UTC
Assigned to new owner.
Comment 19 Jaroslav Tulach 2005-12-08 11:09:31 UTC
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 
 
Comment 20 Lukas Hasik 2008-04-10 21:15:19 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 21 Jaroslav Tulach 2008-07-17 22:05:52 UTC
I guess we have Actions.alwaysEnabled and TopComponent.openAction now in 6.5 and that is all we can hope for...
Comment 22 Jaroslav Tulach 2008-07-17 22:08:34 UTC
*** Issue 70280 has been marked as a duplicate of this issue. ***
Comment 23 Jesse Glick 2008-07-17 22:18:19 UTC
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.
Comment 24 Jesse Glick 2009-08-04 16:08:10 UTC
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.
Comment 25 Jesse Glick 2009-08-04 16:08:49 UTC
*** Issue 13540 has been marked as a duplicate of this issue. ***