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.
there's a need for a generic notifications api that would allow informing the user about various events in an unobtrusive way. examples of such events are 'updates available', 'hudson build failed', 'instant messaging events'.
the API and a working implementation is available in cdev clone: api changes: http://hg.netbeans.org/cdev/file/0f064714ef49/openide.awt/apichanges.xml java api: http://hg.netbeans.org/cdev/file/0f064714ef49/openide.awt/src/org/openide/awt/NotificationDisplayer.java http://hg.netbeans.org/cdev/file/0f064714ef49/openide.awt/src/org/openide/awt/Notification.java the api is implemented in core.ui module
i posted wrong urls, the correct ones are: api changes: http://hg.netbeans.org/cdev/file/f06da6bf861c/openide.awt/apichanges.xml http://hg.netbeans.org/cdev/file/f06da6bf861c/openide.awt/src/org/openide/awt/NotificationDisplayer.java http://hg.netbeans.org/cdev/file/f06da6bf861c/openide.awt/src/org/openide/awt/Notification.java
Y01 A "tck" test showing behaviour of SimpleDisplayer and some complex one in core.windows is the same would be nice.
I am using it without problems so far. I have not attempted to use the facility to inject a custom JComponent. getDefault is missing Javadoc. Should specify that it looks for an impl in lookup and has a fallback. It is not necessary to specify @throws NullPointerException for null args; _all_ NB APIs are presumed to never accept or return null unless otherwise specified.
i fixed the javadoc. all changes should propagate to the main repo soon since cdev has been converted to regular team repo Y01: what's 'tck' test?
Re. TCK. See http://openide.netbeans.org/tutorial/test-patterns.html, section "Testing Foreign Code". In your situation you would have a test in openide.awt. You would run it once to verify openide.awt's impl is OK. You would run it for second time to test that core.ui's impl is OK.
[JG01] See issue #160945. Behavior must be documented (in Javadoc for each applicable method) w.r.t. use of HTML in strings. Possible choices: 1. HTML is not permitted. #160945 must be backed out, and hudson module must not use it. 2. HTML is required. Any modules constructing strings from arbitrary sources should use XMLUtil.escapeForElementContent to make sure stray '<'s are not interpreted as tags etc. 3. HTML is permitted if a method returns a value beginning with "<html>". #160945 should be backed out, but impl code should be reviewed for any place where an API-supplied string is concatenated with any other string - in which case "<html>" may need to be moved to the front of the compound string, or the non-API-supplied portion may need to be escaped.
[JG01] - i implemented your suggested option 1. html is used in api impl to create link-like buttons so html tags inside the text may lead to visual discrepancies NotificationDisplayer.notify( String, Icon, JComponent, JComponent, Priority) can be used for notifications with custom-rendered content core-main a095e36b5f97
Integrated into 'main-golden', will be available in build *200903281400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/a095e36b5f97 User: S. Aubrecht <saubrecht@netbeans.org> Log: #159614 - don't allow html tags in notification texts