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 9679 - Boldface default actions and properties
Summary: Boldface default actions and properties
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jaroslav Tulach
Keywords: API, UI
: 18761 20772 (view as bug list)
Depends on: 35827
Blocks: 17597
  Show dependency tree
Reported: 2001-02-18 22:42 UTC by Jesse Glick
Modified: 2013-09-18 14:24 UTC (History)
8 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2001-02-18 22:42:10 UTC
Would be nice if:

1. The default action for a node (what happens when you double-click it) were
boldfaced, as it is in e.g. the Windows GUI.

2. If a node property is marked "preferred" or something similar (or a bean node
is showing a JavaBean with a preferred or default property), it could be
boldfaced too, to highlight it.

#2 would probably not be difficult. #1 would probably require an API change, I
am not sure how to do it.
Comment 1 Jaroslav Tulach 2001-03-13 10:12:01 UTC
David, #2 is for property sheet. #1 leave to somebody else.
Comment 2 Jesse Glick 2001-03-13 14:46:24 UTC
Trung may have an opinion on the BeanNode bridge, as experiences in the Form
Editor indicate that bean properties often use this hints quite illogically.
Comment 3 _ ttran 2001-03-13 15:59:36 UTC
not sure David is talking about boldface in what.  I assume names of properties
in property sheets.  My first reaction is "please don't do it", if there is only
one or two "preferred" items then boldface is fine, but when you have twenty...
 In Component Inspector and property sheets for form components preferred
properties are displayed in a separate sheet.  It's better this way.

Jesse is right, most BeanInfos are buggy in marking "preferred" and "expert". 
Don't rely on them.  An additional downside is that if you do people will start
filing bugs against your property sheets because they don't know the bug is in
BeanInfo which belongs to someone else :-)

Comment 4 Jan Chalupa 2001-05-06 08:12:38 UTC
Target milestone -> 3.3
Comment 5 Jan Chalupa 2001-11-27 13:03:16 UTC
Target milestone -> 3.3.1.
Comment 6 David Simonek 2002-02-06 15:02:19 UTC
I expect importance of this is low - I'm setting 4.0 as target. First
part has to do something with actions, creating dependency.
For second part I agree with Trung. (vote to don't do it).
Comment 7 David Simonek 2002-07-26 13:34:35 UTC
raising priority a bit and passing to UI team to confirm that it's ok
from UI perspective.
Comment 8 David Simonek 2002-07-29 15:09:08 UTC
*** Issue 18761 has been marked as a duplicate of this issue. ***
Comment 9 _ tboudreau 2003-05-17 23:07:36 UTC
Note this could be yet another use case for the proposed
rendering hints mini-api (along with explorer nodes, tabs in
tabbed panes and properties in the property sheet).
Comment 10 jrojcek 2003-06-11 10:51:32 UTC
I agree with #1. It is useful enhancement. Sometimes it is hard to
guess what the default action really is.

#2 should not be implemented. Bold text in any IDE window might make
it looking more important than an information provided in other
windows, what might not be really true. So, we should be very careful
with that.
Comment 11 Jesse Glick 2003-06-18 01:32:16 UTC
Tim - the rendering API is not helpful here. It is trivial to boldface
a menu item *if you make the JMenuItem*. Just set the Font correctly
or something. You could do it with an HTML rendering tip, but you
certainly don't need that.

The trouble is that the creation of the JMenuItem is in most cases
controlled by the action, in Presenter.Popup.getPopupPresenter()
method. But only the context menu knows which action should be the
default in that menu. It has no way of communicating this fact to the
action. If we added e.g.

/** ugly name, just for example */
public interface Presenter.Popup2 extends Popup {
    JMenuItem getPopupPresenter(boolean defaultChoice);

then we could do it - hence the need for an API change.

I have also separately complained that JInlineMenu is extremely evil
and is only needed quite artifically to deal with the fact that
Presenter.{Menu,Popup}.get{Menu,Popup}Presenter() returns only a
single JMenuItem, when sometimes a list is needed. We could deprecate
Presenter.{Menu,Popup} and create e.g.

public interface MenuPresenter {
    JMenuItem[] getMenuPresenters();
public interface PopupPresenter {
    JMenuItem[] getPopupPresenters(boolean defaultChoice);

which would kill two birds with one (API) stone.
Comment 12 Jiri Rechtacek 2004-04-23 10:45:23 UTC
Assigned to new owner.
Comment 13 Milos Kleint 2005-05-10 12:53:56 UTC
  JMenuItem[] getPopupPresenters(boolean defaultChoice);

version of the api change looks buggy to me, which one of the JMenuItems shall
be the default one? or all of them? meaning a fileSystemAction will have 1-x
boldfaced items if it were the default?
Comment 14 Jesse Glick 2005-05-10 13:56:42 UTC
To Milos' last question - I don't see a problem. It is up to the implementor of
the method to boldface the appropriate item, if there is one.

In the case of a VCS action provider, probably this parameter would be ignored
because you cannot set FileSystemAction as the default action for the node - or
rather you could, but it would be useless since actionPerformed does nothing.
I.e. the main action does not correspond to *any* of the menu items.

However for PasteAction it is meaningful since there are >= 0 PasteType's at any
given time, and PasteAction.actionPerformed runs the first available (if any);
so if getPopupPresenters(true) is called, the first menu item (if any) should be
boldfaced, and the others not.
Comment 15 Jesse Glick 2005-05-10 13:57:37 UTC
Milos had a comment but was not on CC, fixing - see my previous comment.
Comment 16 Jiri Kopsa 2005-11-07 18:17:15 UTC
What is the current state of this issue? And is issue #20772 duplicate of this one?
Comment 17 Jesse Glick 2005-11-08 00:24:33 UTC
*** Issue 20772 has been marked as a duplicate of this issue. ***
Comment 18 Jiri Kopsa 2006-02-02 16:17:29 UTC
I still wonder what is the state of this issue.
Comment 19 Antonin Nebuzelsky 2008-02-07 16:02:35 UTC
Reassigning to new module owner Tomas Holy.
Comment 20 Jaroslav Tulach 2010-04-02 06:45:25 UTC
Interesting, but not really necessary. We could live nine years without it. If you want that provide a patch.
Comment 21 mccorb 2013-09-17 21:39:00 UTC
Just so people know...all you have to do to get the default action be bold is to do this...

class MyAction extends AbstractAction
    super("<html><b>bold action</html>");

Just make sure the getPreferredAction() matches the bolded action class and the problem is solved...
Comment 22 Jesse Glick 2013-09-18 14:24:09 UTC
@mccorb: of course as the author of a particular action you can easily make its label boldface. The problem is to automatically boldface the preferred action in any context menu, without touching the action code, and keeping in mind that one node may set Edit as preferred while another sets Open as preferred, etc.