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.
Per recent suggestion on dev@openide - the initial learning curve for Nodes is greater than it needs to be for many common, simple uses. The concept that a Node has a Children object and that both need to be implemented is more than a user really needs to know. There are a number of other cases which require subclassing AbstractNode which a support class could eliminate: - HTML error marking + icon badging - subclasses in mobility and javacard to use putValue(someKey, Boolean.TRUE) to turn on an error badge - Providing an already instantiated Image as an icon - Suppressing the built-in Properties action returned by default by getActions(boolean) And a few things which are non-intuitive, which could be handled more simply - Allow creation of the Lookup after the call to the superclass constructor (eliminates some awkward constructs such as constructor-chaining to store an InstanceContent in a local field, and cases where lookup contents are fixed, but AbstractLookup+InstanceContent must be used because the Lookup contents are inner classes of the Node and cannot be created until a reference to "this" is available) - Provide a way to pass fixed Lookup contents directly as an array I will attach a patch which adds org.openide.nodes.SimpleNode which addresses these issues (if you can think of other common issues that could be usefully solved, please add them here).
*** Issue 174804 has been marked as a duplicate of this issue. ***
Created attachment 89650 [details] Patch adding SimpleNode to nodes api
Added API_REVIEW_FAST keyword
Why only error badge, isn't it more useful to allow any badges on any location of the badged node? Something like a method "addBadge(String id, Image badgeImage, int x, int y, ...)". I think this functionality might be appreciated...
I looked it over and think it will be a nice improvement for simple cases, which in my experience make up at least 90% of cases for platform-based applications.
I meant to add that I agree with Petr's suggestion; we often use badging to show the user whether a calculation is solved, in progress, failed, unsolvable or other states. I do note that getIcon(int type) is not marked final, so I could still achieve what I need by overriding this method as I do now, but I think it would be relatively common for the IDE and platform applications to denote additional states beyond just errors using badges.
Some sort of general badging feature could be nice. However, it could get complicated quickly - what order are they painted in if they overlap, and will that be consistent? How do you remove a "badge" - do you hold a reference to a small image file forever? Use some sort of id or token as in Petr's suggestion? Have an actual abstract Badge class that implements Comparable and a factory method that can be passed an image path (this would quickly become reinventing Icon)? While I don't want the perfect to become the enemy of the good here, making the API simple for this might be at cross-purposes with performance. I like the idea of it, but would like to see an improved patch that does it cleanly.
Also, just modifying an icon does not really meet accessibility requirements (never rely on just one visual aspect to be perceived) - at least in theory, a badge should always be paired with some textual change such as font color, style or weight. So it seems like icon badging and adding prefixes to the HTML display name go hand-in-hand. Just food for thought...
I am not opposed to the change, but I need a volunteer to pass the API review and integrate it.