We want to build a simple version of a global action list that will let the user see all actions in the application an edit them. This simple version should be quick to build and easy to use while not precluding a more advanced version in the future. It should reuse as much existing code and dialogs as possible.

The editor should have a list or table of global actions.

It should be as simple as possible. Remove most of the columns from the previous mockup.

The user should be able to double click an action to edit it. Coleen There should probably be a more obvious way of accessing the editor as well (an "edit action" button perhaps).

Where should it go? Coleen My gut reaction is to say that all high-level properties views like this (I've been calling them editors in the spec: http://xdesign.sfbay/projects/java/j2se/7/tools/research/spec-appshells.html#5.0 ) live under the Resource Editors node (or equivalent) in the Projects view since they seem like similar beasts. They should probably have similar designs as well (placement of widgets, filtering, task flow, etc.)

Which columns to remove and simplify? Josh We probably could show the text and mnemonic and accelerator together. Something like: S_ave ^S Where '_' represents an underlined 'a'. That would combine three into one and show it similar to how it would appear at runtime in a menu item. We might be able to do the same with icons as well. If the icon is bigger then we could have a rollover tooltip to show the full icon. I do think we should leave in the method signature, though. It's a very important part of the action. That's why we moved it to the top prominent place of the Action Property Editor.

Editability: Coleen I personally think that if the user only has a few basic things she needs to edit for an action and those items are right there in the table, she should be able to edit them without having to open up a new window.

new mockup

In this more simplified mockup we have combined the text, mnemonic, and accelerator properties into a single field. I'm not sure the user would edit this inline, however. Perhaps it would reveal 3 sub-fields when you double click to edit?

This table should be sortable.

Where should this table live? How do you access it?

If the user double clicks on a row (possible?) or selects the Edit Action button, then the standard Action Property Editor field will appear.

The method name is listed here but currently not editable. Unless we decide that the method property of an action *should* be editable.

What other properties should be here?

Can you edit the icon here or is it readonly and you must use the property dialog?


Deleting methods:

I think the method should be deleted including all resources. Not sure if we should offer to only remove the annotation. The user should be able to find out if the action is being used - maybe that also means to check direct calls of the method (means to run "Find usages" in background; not sure how much work that means).

Related question: Should undo/redo work in the action list?

Deleting the method sounds dangerous. How about if we comment it out. Something like this:

/* // this action was deleted from the global action list @Action public void myActionMethod() {



  • /

This we we don't accidentally delete someone's code. Resources are easy to restore by hand. Code isn't.

Creating a new method:

When you add an action where should it go?

   We would open the Action Property Editor and the Create New Action panel the same way we do now. However, we need a way to choose which class the action should go in. It's not clear where this would go.

What about a wizard? First panel would be a source file chooser, second the New Action panel, third the actual action editor?

A wizard seems overkill for creating a new action, but maybe I'm missing something. Can't we accommodate adding a new action via just one small secondary window?

Probably yes. This is the New Action dialog, right? Note that unlike with action editor you also need to choose a class where the action will go. That's another window to show (some kind of file chooser). After closing the New Action dialog you'd probably want to open the dialog for editing.

One more comment to the new mockup of the action list: I think selecting the class via combo box is not ideal - given the potential number of classes. A separate class chooser would be better (e.g. invoked by selecting a "..."-like item in the combo box?).

reason to exist

Sounds like you're struggling with the main reason for this dialog to exist. That is, why would someone want to use it? I could see using it as a nice roll-up of all the actions I've created and exist throughout the project. Given we have the action editor already, I don't know that you need to duplicate that logic.

The missing piece I would like to know, and this holds true for resources as well, is what @Actions and resources are not being used and just dead code? It would be cool if you could show what @Actions are unused, and ideally where @Actions are used.

We need to have a single place to see all of the actions throughout the project. It's a way of getting a handle on what you have and where it is. Imagine I've just been put on a project that already has existing code built to the app framework spec. Wouldn't it be nice to see a list of all actions, which classes they are in, and which components they are bound to?

We could certainly show unbound actions in a different color. Red text, perhaps? Or an orange background?

I agree finding the usages is important. That can hardly be done by other means (e.g. not via Find Usages - Alt+F7). It might not be trivial to implement... Navigation seems to be another important use case (jumping to code of the action method, jumping to code of the use of the action).

existing mockups and designs



other stuff

Currently we don't have a way to set platform specific information visually, either from the global action list or the action property editor. Should we?

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo