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 32256

Summary: Add support for rollover, disabled and pressed icons
Product: platform Reporter: David Strupl <dstrupl>
Component: ActionsAssignee: David Strupl <dstrupl>
Severity: blocker CC: apireviews, jglick, jtulach, ttran
Priority: P3 Keywords: API, API_REVIEW_FAST
Version: 3.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 38378, 38542    
Bug Blocks: 32488    

Description David Strupl 2003-03-24 21:43:37 UTC
It should be possible to specify a special icon
for each state of the (mainly) toolbar buttons.
Can this be done without API change? BTW when I
use javax.swing.Action how do I specify an icon?
(Do I have to implement also Presenter.Toolbar?
Any better way?) Thanks for your suggestions.
Comment 1 Jesse Glick 2003-03-24 22:28:23 UTC
You can use Presenter.Toolbar to get special behavior like this. I am
not sure if it is worth supporting this generally, unless it seems a
common need (not met by the default grey-out behavior etc.).

If using Action, you can implement Presenter.Toolbar if you wish, but
it should be optional; see Action.SMALL_ICON.
Comment 2 David Strupl 2003-03-24 23:36:53 UTC
Ok - I will probably be able to create a support class implementing
javax.swing.Action and Presenter.Toolbar that would be used for all
new actions created by the developers of that app. But what if we need
to add this kind of bahaviour to some of the actions that NB provides
(like cut, copy, paste, maybe some others). Should I create a sort of
wrapper actions for all of these that would implement
Presenter.Toolbar? Or I can create a bunch of properties similar to
Action.SMALL_ICON and the actions would supply these. And the UI for
ToolbarButton (or the ToolbaButton itself) could read them. Still have
the problem with the standard actions. Hmmm... lets see. I will try to
provide patches. I can provide also a patch that is an API change (in
fact this patch from someone else is my starting point). If it is not
accepted (acceptable) we will still be able to use it but I would like
to keep all the modifications to openide on I might try to put
the changes to my private branch (of couple of files) to see how big
the changes would be. If the branch will go to the trunk can be
decided later.
Comment 3 Jaroslav Tulach 2003-03-25 17:02:28 UTC

The default presenter for javax.swing.Action if not implementing
Toolbar.Presenter is org.openide.awt.Actions.connect which uses
action.getValue (Action.SMALL_ICON);

It also listens on property changes, so you can update the icon
depending on state.
Comment 4 David Strupl 2003-04-02 20:33:00 UTC
Incompatible API change on the branch platform_32247. If there would
be a clean way it would be better. But remember that this patch allows
also for making the icons for standard netbeans actions like
CopyAction, CutAction, ...

Checking in awt/;
/cvs/openide/src/org/openide/awt/,v  <--
new revision:; previous revision: 1.84
Checking in awt/;
/cvs/openide/src/org/openide/awt/,v  <--
new revision:; previous revision: 1.21
Processing log script arguments...
More commits to come...
Checking in util/actions/;
/cvs/openide/src/org/openide/util/actions/,v  <--
new revision:; previous revision: 1.68
Comment 5 David Strupl 2004-01-02 22:20:20 UTC
I have made the API change minimal with Jarda's help. Now the only API
change is in the support of ("iconBase",<path to the icons>) custom
parameter pair with javax.swing.Action.putValue(key, value).

The implementation diff is here:
or maybe better directly look at revision of

This implementation also ensures that the old SystemActions can use
the rollover, disabled and pressed icons - if the gif files are
present together with the main gif file for the action.

Please review the change.
Comment 6 Jesse Glick 2004-01-03 22:39:22 UTC
Reflective use of SystemAction.iconResource() here is pretty ugly. On
the other hand the proposed patch hides the change pretty well so it
can be easily deleted in the future if and when javax.swing.Action
gets proper constants for these keys (e.g. ICON_ROLLOVER etc.).

Shouldn't there be some accompanying documentation here? Probably in
o.o.a.Actions class Javadoc, with a link to it from
SystemAction.iconResource? And a note in

Also openide/arch/arch-openide-actions.xml#exec-privateaccess should
be amended.
Comment 7 David Strupl 2004-01-03 22:59:26 UTC
I will update the docs when doing the commit to the trunk. Also the
diff here is against release35 - I will port it to the trunk after
this change is agreed upon. I know about the reflection but I could
not resist to use the method (iconResource) from SystemAction when it
was already there and heavily used from all the subclasses. This works
pretty nicely - we have already added all the icons for the standard
NB actions (in our version of release35).
Comment 8 Jaroslav Tulach 2004-01-05 08:52:32 UTC
1. Any tests to execute? I have a suggestion for a change, how shall I
verify that it is valid?

2. Ok, if I cannot verify, I am going to shout it: Would not it
possible and simpler to replace the reflection with small enhancement
in SystemAction:

public Object SystemAction.getValue (String key) {
  if ("iconBase".equals (key)) {
    return iconResource ().stripOff (".gif");

  // and the rest of the method...

for what I can see that would have the same behaviour and you could
delete the Actions.iconResource trick completelly. But as I said, no
tests == no way to verify.
Comment 9 Jesse Glick 2004-01-05 15:58:13 UTC
Yes, the proposed SystemAction.getValue modification looks much nicer
to me... then, I guess, a SystemAction would behave just like any
Action w.r.t. the "iconBase" special key?
Comment 10 David Strupl 2004-01-07 12:33:22 UTC
I agree with the change to SystemAction. I will put your solution when
commiting to the trunk. The tests were added to the issue - they will
be commited together with the patch and the docs.
Comment 11 David Strupl 2004-01-07 20:37:16 UTC
If there are no objections I plan to commit the change to the trunk
during tomorrow.
Comment 12 David Strupl 2004-01-08 11:47:50 UTC
The changes are in the trunk now:
Checking in;
/cvs/openide/,v  <--
new revision: 1.130; previous revision: 1.129
Processing log script arguments...
More commits to come...
Checking in api/doc/changes/apichanges.xml;
/cvs/openide/api/doc/changes/apichanges.xml,v  <--  apichanges.xml
new revision: 1.183; previous revision: 1.182
Processing log script arguments...
More commits to come...
Checking in arch/arch-openide-actions.xml;
/cvs/openide/arch/arch-openide-actions.xml,v  <-- 
new revision: 1.19; previous revision: 1.18
Processing log script arguments...
More commits to come...
Checking in src/org/openide/awt/;
/cvs/openide/src/org/openide/awt/,v  <--
new revision: 1.88; previous revision: 1.87
Processing log script arguments...
More commits to come...
Checking in src/org/openide/util/actions/;
/cvs/openide/src/org/openide/util/actions/,v  <--
new revision: 1.71; previous revision: 1.70
Processing log script arguments...
More commits to come...
RCS file: /cvs/openide/test/unit/src/org/openide/awt/,v
Checking in test/unit/src/org/openide/awt/;
/cvs/openide/test/unit/src/org/openide/awt/,v  <--
initial revision: 1.1
Processing log script arguments...
More commits to come...
RCS file: /cvs/openide/test/unit/src/org/openide/awt/data/testIcon.gif,v
Checking in test/unit/src/org/openide/awt/data/testIcon.gif;
/cvs/openide/test/unit/src/org/openide/awt/data/testIcon.gif,v  <-- 
initial revision: 1.1
RCS file:
Checking in test/unit/src/org/openide/awt/data/testIcon_disabled.gif;
 <--  testIcon_disabled.gif
initial revision: 1.1
RCS file:
Checking in test/unit/src/org/openide/awt/data/testIcon_pressed.gif;
 <--  testIcon_pressed.gif
initial revision: 1.1
RCS file:
Checking in test/unit/src/org/openide/awt/data/testIcon_rollover.gif;
 <--  testIcon_rollover.gif
initial revision: 1.1
Processing log script arguments...
Mailing the commit message to (from