The central place for rework of Actions API

Changes: 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 SystemAction has been changed to implement the javax.swing.Action 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 /Action folder 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) org.openide.awt.JInlineMenu component
    Solved: Use org.openide.util.awt.DynamicMenuContent instead of the org.openide.awt.JInlineMenu
  • 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.

The work is tracked under issue 70280 and described in the living proposal.


Links to related documents


Send comments and patches to nbdev@netbeans.org or attach them to issue 17597. Please create the patches to current version of the document.

Project Features

About this Project

openide was started in November 2009, is owned by Antonin Nebuzelsky, and has 33 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close