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.
Netbeans is not very good about informing the user the type of items shown in the Explorer (all you really have to go on is the icon). This particularly a problem for new users, who don't know our icons, and will become even more of an issue with the proposed icon badging, as users may wonder things like "what does it mean when the icon has a green arrow or a red star on it?") And it is better not to use tooltips for this information, as tooltips are usually more irritating than helpful, I would hate to run my cursor over the explorer if every row had a tooltip defined! Instead, I see that the status line is not often used by Netbeans. So, I would suggest that the description of the selected type could be displayed on the status line. This might possibly be done by the system invoking an optional method on the node instance, to get a description of the node suitable for showing the user (e.g. getUserTypeName()), and then displaying that text on the status line. Text examples might be: "Java Class", "Executable Java Class", "EJB", "Java Applet", "Java Class with Merge Error", etc. (each Node type would be responsible for constructing its text).
note that individual explorer nodes shouldn't try to use the status line until some sort of top-level change like that described here is implemented. That's because even if a node could figure out how to write to the status line every time it is selected, that wouldn't be a good idea, because you wouldn't want to leave that text on the status line after the user selects a different node. That line needs to be repainted or cleared when another node is selected. Thus a top-level fix would be best, and that would make the status line useable by Explorer nodes.
I think status bar is not very suitable solution for describing selected node. As I have followed dicsussion about this issue on [nbui], one of of the objections was that it can be obliterated by some subsequent operation. You can protest it can be rare situation and user may reselect node to see its description again. But in addition status bar should be extended for better showing of statuses of running processes (Global Status Indicator proposal). And that is the purpose of status bar - show status of some *process*, not of some static object, I think. Tooltip is quite appropriate place, isn't it? I know, you're saying: tooltips are very obtrusive. But then, what is their purpose? On the other hand, why is the help the last instance of information? All this kind of information *should* be in the IDE help, and IMHO help is a first place where user should try to find info about that, but that's another story... So, what do you think about tooltips?
reassigned
Target milestone -> 3.3.1.
I'd like to address a couple of the questions addressed in previous comment (one by Gabriel Tichy). 1. Showing status of running process is fine, but we would still need a place to show non-dynamic status information and those two don't have to overlap; if you want to use the status bar for running process, then you could segment the status bar into two pieces when the running processs status is needed (one part for the static status, and newly created part for running process). Or, make it permanent, if it will be needed often. 2. Best use for tooltips is to explain the purpose of a button that user might not otherwise understand; they are especially useful for buttons that don't contain text, such as those seen on Web Browser button bar. Other uses, such as on tabs in netbeans source editor can be irritating more often than they are useful. Tooltips should be used with caution for this reason. While it may sound good on the surface to show tooltips on explorer nodes to explain what the icon means, the irritation factor would be huge since the explorer is a common place where people work when you don't want to see a tooltip, so that approach should definately be avoided. If done, I predict that many users would insist on a way to turn explorer tooltips off (which would indicate a design problem). In summary, tooltips should be used sparingly because of the irritation factor they create. If a tooltip may show up often when the user doesn't want to see it, then another approach should be used. And I believe tooltips would often show up when not wanted if used in the explorer. The status line, on the other hand, doesn't have any of these problems. It is simple, unobtrusive, and users learn very quickly that to find out the type of an item in the explorer (as well as in any other workshop), they just select it and then read what it is in the status bar; clicking somewhwere else after that clears or resets the status, but that is the expected behavior.
I think the right approach to this issue is to just take it as a goal to find a way to display information about static nodes. Tooltips don't work well, because of the proliferation of nodes. The status bar won't work well, because it doesn't have a strong enough association with nodes (i.e., users won't look there), and because the message could get obliterated for a variety of reasons. Instead, I'd like to brainstorm some other places where this information might go. Here are a couple: 1. In a special "mini status bar" that appears at the bottom of the Explorer tab. This mini status bar could be turned off by the user, perhaps by right-clicking and selecting a context menu item. 2. As a property of the node, e.g., a property called Description. This property would appear on the node's property sheets, and could be longer than a few words if desired. 3. Implementing a "What's This" style help function. The user does some gesture that provides a special cursor (e.g., an arrow with a question mark attached) and then clicks on the desired node. The user gets a blob of information about that node, presented in some kind of large tooltip window. Just some ideas. If we want to pursue this, we should probably move this discussion to nbui. --Dirk
I like all of Dirk's suggestions better than tooltips. Of his 3 suggestions, I like 2 the best, because 1 and 3, if I'm understanding them correctly, would probably have to be implemented on a per- workshop basis. I would prefer a solution that relieves the workshop developer from having to think about identification, or having to write special code to support it. The workshop developer should just invoke a Netbeans method when something new is selected, and Netbeans could take care of displaying the type name of the selection. Then the workshop wouldn't have to implement its own status bar or a special help mode.
change Component field to "Core" next time please set the "component" field correctly. As we see in this case, if the field is not set correctly, the right people won't see it and nothing will be done.
Is this not a dupe of the RFE to add "object type" prop to the property sheet of every node (or vice-versa)?
final ui decision copied from nbui: ----------------------------------- A Node Property. Every node would have a new property, maybe called Description, that appears in the node's property sheet. This property would show read-only text describing the node. Pros: this is probably easy to implement, it fits in well with NetBeans' existing structure, it can be displayed by any node, and it can provide lots of information about the node (through the user of a "..." button). Cons: it may not be noticed by the user. ------------ suggestion 4 >> (icon info in property sheet) received by far most supporting votes >> (personally I support it too), so I'm proposing to mark it as final >> solution, with following sileline attributes: >> - as Maya proposed, give icon annotation property some prominent >> position. Howeverm this is tricky to implement, because properties can >> be sorted by name, unsorted etc. >> - tooltip over this property, showing its full value, as Chris Bishop >> suggested.
This sounds more like "Help" to me - I think the solution could be arrived at by creating a component that will (in the background!) display the help for whatever is selected. Basically, a dynamic help window. User can have it on screen or not, as they wish. The description text we're talking about already exists in the docs, in one form or another - wouldn't it be better to leverage that than add description properties to nodes?
Tim, it seemed consensus was reached on nbui discussion, I put results here to not be forgotten. If you believe your suggestion is better, go on to nbui and open this issue again. Problem is that your suggestion is vague - where the window will be, how it will behave, how we will switch it off/on? - this should be exactly specified. However, I think most of us on nbui was satisfied with property sheet solution, I vote for not changing the solution. Jiri, please take care of implementation of this enhancement. (Yarda and David Strupl will help you for sure if needed).
updating component and subcomponent.
I reopened this problem on nbui because of new merit: This issue is related to discussion about Simplification of navigation in Explore posted by Jiri Mzourek. http://ui.netbeans.org/docs/ui/sx/index.html His proposal includes proposition to not display properties view as default. It goes against finall call for this issue in my opinion.
Look at this reopened discussion on nbui please: http://www.netbeans.org/servlets/BrowseList? listName=nbui&by=thread&from=10728 I choose from Dirk's suggestions first one and you can find some figures for this idea on this address too: http://ui.netbeans.org/docs/ui/nodedesc/ministatusbar_propo sal.html Any comments, objections and ideas ??
I wrote summary about proposed solution into this document: http://ui.netbeans.org/docs/ui/nodedesc/ministatusbar_propo sal.html
having status line in different places depends on the "workspace switcher" issue 8617
The last UI spec will be at http://ui.netbeans.org/docs/ui/nodedesc/ministatusbar_proposal.html. The ministatus line will be attached in each explorer panel at bottom; the line will describe the selected nodes in this explorer panel.
I'm going to add a node's description to main trunk. This node description will be show on a node with the "node_description" property set. For the nodes without any description will be logged a warning. A option "Show a mini status bar" will be added to System Settings with true as default. There was a problem with adding a popup menu with Show node description or Hide node description action because TreeView was in openide and then I was not able to add this action from core's NbMainExplorer. For now there is only a system option in System Settings. Each module owner should be add this "node_description" property with a node description in the a hidden property set on the owned nodes. See a attachment with a example.
Created attachment 5665 [details] a example of adding "node_description" property to a node
The node description was added.
The getting of the nodes description was changes. At first a node is asked for nodeDescription if the node returns null then node.getShortDescription is used. This ensure any description for all nodes. The second change, the important for the node owners, is the way how to set nodeDescription is changed too. It's more easy. During the node creating is call setValue("nodeDescription",<some_message_from_bundle>) enough. The attached example *is not valid* now. At last: who wants see the node descriptions or the No_description warnings then use a property -J-Dnetbeans.log.node.description=true.
I think the ministatus bar approach outlined will be a big step forward, but I wonder if some of these approaches might be complementary. - an option to display the short description of the type in the explorer tree itself might be nice, since then you can find an object of a given type without having to select all the instances - an option to display file extensions in the explorer might also be handy (or am I missing this?) - displaying the node type as part of the properties page seems good, since these windows can float around. Moreover, type properly is a property of an object instance, is it not? This could be especially useful if some day basic type mutations of objects were supported -- kind of handy for allowing programmers to take general objects and specialize them after the fact - separating the localizable short and long description of the type from the immutable name of the type and having both in the property sheet seem like good ideas to me Peter
Cooky *how to set node description*: (it will be added to migration guide soon) A desirable is using Node.PROP_SHORT_DESCRIPTION as long as possible, a node description could bu used in the cases where PROP_SHORT_DESCRIPTION is used with other meaning (e.g. JavaNode). There are tree cases: 1. a node doesn't set any PROP_SHORT_DESCRIPTION (so as short description is used a display name of the node as default) - it *not necessarily* set node's description, we should set the short description - we override getShortDescription method of the node, it returns a description which shows in mini status bar 2. a node returns a description. If this description passes our expectation then ok, it will be used automatically, this description which shows in mini status bar. 3. a node returns a improper description for our expectation. Then we can use the "nodeDescription" attribute. We set this attribute e.g. in node's constructor via call method setValue("nodeDescription",<some_message_from_bundle>) as noted above. Hope it helps, any problems or questions please add here, thanks.
Info how to add a description find at http://openide.netbeans.org/unbranded-source/browse/~checkout~/openide/api/doc/org/openide/doc-files/upgrade.html
And info,which description should be set is at this address: http://ui.netbeans.org/docs/ui/nodedesc/ministatusbar_propo sal.html#list
the implementation doesn't appear to work for Nodes that are wrapped in some FilterNode, I am reopening. Comment from Peter.Nejedly on openide-dev on 2/12/03: "I was trying it and it worked for me, but I think I know where the problem is: FilterNode. I was trying it on MountNode.CapNode for a filesystem node, but this is probably the last FilterNode on the way. FIlterNodes do proxy requests for getShortDescription() but don't proxy requests for getValue(), so if your node is wrapped in some FilterNode (very probable), it won't work. I think this is a deficiency in implementation of #9940, it doesn't work as advertised (for most users). Will you reopen it?"
Because "FilterNodes do proxy requests for getShortDescription() but don't proxy requests for getValue()" I'm going to file new issue against openide/nodes which will block this issue.
Suggest this be closed again, since #31006 is open and captures Peter's problem.
Also suggest this issue be closed - I think the description area in the new property sheet fulfils this requirement. Note: We *do* need better descriptions for nodes! We now display them, but many are not very informative.
I follow Jesse and Tim' advice I close as accomplished.