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.
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.
David, #2 is for property sheet. #1 leave to somebody else.
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.
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 :-)
Target milestone -> 3.3
Target milestone -> 3.3.1.
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).
raising priority a bit and passing to UI team to confirm that it's ok from UI perspective.
*** Issue 18761 has been marked as a duplicate of this issue. ***
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).
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.
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.
Assigned to new owner.
the 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?
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.
Milos had a comment but was not on CC, fixing - see my previous comment.
What is the current state of this issue? And is issue #20772 duplicate of this one? http://www.netbeans.org/issues/show_bug.cgi?id=20772
*** Issue 20772 has been marked as a duplicate of this issue. ***
I still wonder what is the state of this issue.
Reassigning to new module owner Tomas Holy.
Interesting, but not really necessary. We could live nine years without it. If you want that provide a patch.
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...
@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.