The central place for rework of Actions APIChanges: available in CVS
Status: issue 17597
Abstract:The existing NetBeans Actions API is a result of long time evolution. Its origin lays in late 1997. At that time it was created as one of the first APIs in NetBeans. Because then the Swing was really, really young, it started as completely Swing independent. As NetBeans became more and more swing aligned, this had indeed turned into big drawback. The need to converge our and Swing actions system emerged. This has been a long term project split into various phases of which many has been successfully finished already, but some still await to be done. This page describes the overall plan and its current state.
Phase I: Retrofit Our Actions To Swing Interface
- Done in early 3.x days. The
has been changed to implement the
interface. This allowed anyone to treat our actions as standard swing ones
and thus use for example
new JMenuItem(Action)constructor and other standard Swing action related support.
Phase II: Allow Use of Swing Actions In Our APIs
- This required changes in other APIs that used to refer to SystemAction. Most of the work has been done in 3.5 where usage of javax.swing.Action has been allowed in Nodes and TopComponents. Later it was made easy to change menu provided by another module for loaders. In 5.0 version one can add actions to any loader as they all define their actions in layers
Phase III: Workaround UI Problems
- There is no central place for a user to find all actions - module owners are not encouraged to store their actions there
(now we have the list of all actions in
/Actionfolder in layer and other places like Menu use shadows to link to them).
- Callback actions attaching/detaching when a window component is activated/deativated is very easy to be broken and ineffective
(see Callback actions) [Implemented]
Note: This is true also for Node actions (according to changes of global activated nodes) [Implemented]
- Actions that require more than one menu item should be able to achieve this in cleaner way than by usage of (now deprecated)
Solved: Use org.openide.util.awt.DynamicMenuContent instead of the
- All actions should update its state before a menu is shown to prevent resizing and dynamic updates of menu when visible (see Context) [Implemented]
- Because actions are invoked in own processor thread to nonblock other operations, it is hard to write actions that deal with UI and need to be run in AWT thread [fixed for NB after 3.5]
- The current UI for creating and manipulating actions in the Options dialog is clumsy. Many users do not realize that Copy and Paste is the way to do it. The Keyboard Shortcuts... wizard cannot handle general actions. Solved: by options dialog redesign in 5.0.
Phase IV: Align with Swing JDK 1.3
The previous phases defacto get us to state where swing was in JDK 1.2. We can use javax.swing.Action, althrough it is not very easy and we still do not follow the javax.swing.InputMap and javax.swing.ActionMap separation. Phase IV is expected to align the NetBeans and Swing in this area as well. Moreover the gap between actions in the system and those used in editor is going to be lowered as well.
Links to related documents
- Use cases document covers use cases and related scenarios for end users, module writers and platform users. Document attempts to be root document for developer's desingas well as for user interface specifictions.
- User Interface document is a specification of look and feel of actions system.
- Design document discusses and describes the design and implementation decisions of the chosen solutions.
- Enabled/disabled state computing using declarative way.
- Already implemenented changes compared to old Actions system, or upcoming changes currently present in a branch before merge into trunk.
Send comments and patches to firstname.lastname@example.org or attach them to issue 17597. Please create the patches to current version of the document.