Community
Participate
Working Groups
If a generic API for popup notification is created (https://bugs.eclipse.org/bugs/show_bug.cgi?id=177974) , it would be great if it supports Growl on MacOS. Almost every OSX applications use it for notification. This would be a perfect desktop integration on this platform. See http://growl.info/screenshots.php
+1 :)
I had the same thoughts when that bug went by.
I downloaded the growl java binding and got a "Hello world" program to work. A couple of things worth noting: 1. The growl java binding uses Apple's Cocoa binding which I believe is now deprecated. I believe there is a carbon API. Would someone have to create a JNI binding to the carbon API for this to be a production solution? 2. To get hello world to work, I had to add /System/Library/Java as an external directory in the java project and then add it to the build path. I have no idea how to get an external directory on a plug-in classpath. This is only a problem if we want to experiment with the current growl java API.
This is by no means diffinitive but... given that we don't currently have any other Cocoa-Java dependencies we'd probably go with a Carbon binding through custom natives or even an executable/Applescript binding.
Carbon is the deprecated API. One way to import these libraries could be to use the import-packages directive of OSGI bundles and ensure Java is started with the mac system java library in the classpath. (I don't know if this will work, but it's worth testing)
(In reply to comment #5) > Carbon is the deprecated API. From http://developer.apple.com/qa/qa2001/qa1342.html "Additionally, the Cocoa-Java API is deprecated as of Mac OS X Tiger."
I suppose the JNI layer could call the growl cocoa API instead of the carbon API. I believe there are technical reasons why SWT is not using cocoa - do those reasons apply here?
I will talk with the SWT guys about this. The reasons may no longer be valid. I am also going to mark this dependent on bug 177974. If we're going to use Growl then the shape of the API sketched out in bug 177974 needs to be consistent (or at least not in conflict with) the output of that bug.
FYI, I just saw on the swt-dev mailing list that they are working on Cocoa SWT. This is very encouraging :)
Jazz (based on Carbon Eclipse) supports Growl for more than a year. Why do we need Cocoa for that?
Andre: Is this something Jazz would be interested in contributing back to Eclipse?
Fyi, the notification work I'm doing on bug 177974 will provide an extension point that allows notifications to be shown with an alternative UI, e.g. Growl. Regarding Growl specifically, can the Growl integration be made a part of Platform/UI since Growl is not a part of Mac OS? In general I think that we're in a weird space with desktop notifications because none of the OS's provide a suitable API for displaying them, so most of the efforts on bug 177974 have been on making nice Eclipse-style notifications. But I work alongside Mac users and I certainly appreciate the desire to have common notifications when a mechanism is there, so we'll make sure that it's easy to plug-in.
Will investigate further in 3.5
(In reply to comment #12) > In general I think that we're in a weird space with desktop notifications > because none of the OS's provide a suitable API for displaying them, so most of > the efforts on bug 177974 have been on making nice Eclipse-style notifications. Actually - there are already similar notification frameworks available for Winows and Linux desktops: Sanrl (wor windows): http://www.fullphat.net/ Mumbles (for Linux): http://www.mumbles-project.org/
Jazz is very interested in Platform API for 3.5 and we would like to give some more detail on our needs in this area. For those that have a Jazz account, [1] describes the notification system in detail. In short, this is what Jazz has come up to to provide extensible notifications: RTC provides a very generic and extensible framework for notifications and events. The framework defines the following terms in order to describe its functionality * Notifier * Events * Trigger A Notifier is a mechanism to inform the user about a certain Event. For instance, the alert-notifier opens a small alert above the tray-area to inform the user about an Event. The Event provides a generic description that is used by the UI of the Notifier. E.g. the Event provides a description, severity and priority. Lastly, a Trigger defines the enabled-state of a certain Notifier for a certain Event. E.g., a Trigger may define to show the alert-notifier for high-severity work item change-events. Thus, a Trigger is the combination of a Notifier and a family of Events under a certain condition. In the attached screenshot of the "Notifications" preferences page you will see the three terms in action. On the left hand side is the list of contributed event categories and types. Top right you can see the event triggers. The selected one will highlight high priority events in red. As you can see, this is totally independent from showing an alert. The idea is that a notification can have any UI (this is extensible, e.g. Growl is one way to show a notification). Finally in the lower right corner, a list of contributed Notifier is showing. Sending events is easy. A static method Notification.send(String eventTypeId, NotificationInfo info) is provided to issue a notification for the given event type. The NotificationInfo is made up of: * image * title * message * category * priority * severity * detail (any metadata being transported) * runnable (executed on click) Jazz is very interested in using Platform API in 3.5 to align notifications through out custom Eclipse/Jazz installations. For us to adopt the platform API, we need both the core and the ui functionality that is already provided in Jazz. I am happy to discuss our needs and strategies on this topic. Ben [1] https://jazz.net/wiki/bin/view/Main/FoundationNotifierTutorial
Created attachment 109504 [details] Notifications preferences page in Jazz This is the notifications preferences page in Jazz.
Created attachment 109505 [details] Alert popup in Jazz This is an example of a Jazz alert that has multiple entries stacked.
After discussion with Andre, we see three layers for notifications: - a sum of Notifiers like Growl support or an Alert widget as Mylin is providing one. those widgets should be capable of showing any number of notifications. this includes support for showing multiple notifications at once (e.g. by stacking them and providing navigational controls to step through them if desired). - a low level API to submit an Event. based on the user preference, a certain notifier (Growl, Alert,...) will be triggered to show the Event to the user. - a high level API to combine Events and Notifiers with a Trigger (as implemented by Jazz currently). We think that the third Layer is not something that would fit into the Eclipse Platform easily, but the first two would solve the problem of a) avoiding multiple variants of notifier implementations throughout products and b) supporting "exotic" notification mechanisms like Growl if provided by the platform.
Kim, Ben: As per our email coordination, let's have a chat about this on next Tuesday's Mylyn call: http://wiki.eclipse.org/Mylyn/Meetings Others interested in design discussion can also join in.
I took a first pass at the wiki page which summarizes our call and which we can use for ongoing discussion: http://wiki.eclipse.org/Platform_UI/Notifications
Mik, sorry I missed the call today. In response to your comment 20 and continuing discussion in the wiki, I added one bullet point under Requirements to provide adaptable color for eclipse-based notification popups. We don't yet do this in Jazz but some basic specs could be provided to facilitate this. I wasn't sure if this was something that would come from the platform or the extensions so I've nested it under the latter for now. Some now old examples of this can be seen here: http://wiki.eclipse.org/09052007Notifications.
Thanks Mik. I have updated the wiki topic to reflect Jazz' needs in this area. @Kimberly: Should we attach the latest UI design for alerts in Jazz to the wiki topic to give some UI-input? Or is there ongoing exploration in this area over the next iteration?
Yes, the adaptable colors definitely make sense. I think that Mylyn's current popups already support this since we use the same approach as forms for deriving colors, but I haven't verified. This raises a related issue. Another thing that we're planning on providing in Mylyn Commons is an Eclipse-styled tooltip. Mylyn relies heavily on tooltips to allow users to preview things like incoming comments before clicking to open. We're currently emulating the Windows XP-ish yellow tooltips that JDT uses and they're looking pretty lame. Ideally we would be using native tooltips (e.g. Vista's gray gradient ones), but I'm not sure if that's possible in a way where we can get our SWT composites into the tooltip. So I think we're stuck making custom ones. If so, I think they should share look and feel with the popups, generate their colors the same way, etc. I've been thinking that basing the look-and-feel of both the default notification popups and tooltips on the view/editor tab style and Forms could make the most sense because that's the most Eclipse-specific bit of look-and-feel, and is the approach we've already taken with the popups. This is possible to do without coupling to Forms, as per Ben's original patch which duplicates deriving colors, etc.
Mik, I am glad you talk about tooltips, because I have exactly the same feeling. In Jazz we have our own implementation of a tooltip that can be used easily across the entire UI (not limited to the Editor) while supporting a rich UI (using a Browser widget and HTML) and a focus-state (pressing F2). Now that Eclipse 3.4. provides a way to make a editor-tooltip sticky by moving the mouse into, users ask for this feature in Jazz too. I am having a hard time implementing this for our tooltips because its so much disconnected from the editor-tooltip-framework. I wish the platform would consider a tooltip-framework that anybody could use easily in the entire UI with the same features as the current editor-tooltip.
(In reply to comment #23) > We're currently emulating the Windows XP-ish yellow tooltips that JDT > uses and they're looking pretty lame. Ideally we would be using native > tooltips (e.g. Vista's gray gradient ones), but I'm not sure if that's possible > in a way where we can get our SWT composites into the tooltip. Others have complained about this before, see bug 174191.
Kim Horne: Should we consider a new Platform UI bug on improving tooltips? Or maybe this is a consideration. On Mylyn are still extending org.eclipse.jface.window.ToolTip but do a bunch of manual stuff, including custom multi-monitor and platform-specific handling. Ben: Good to hear that we're hitting the same problems in this respect too. The stickiness is one where there is particular overlap with the notification popups. For example, I would love to see some the current popup behavior we have (e.g., fast fade in of tooltip, sticky on hover, fade out on mouse exit) working for tooltips, and ensure that overlaps nicely with focus-state. And as you point out, we really need a common framework for this because it will be super weird to have different tools with their own look-and-feel for tooltips. I'm guessing that Jazz will still want to have additional behavior than we have requirement for in terms of progressive disclosure via tooltips, but it seems that the core look and feel should be consistent.
Created attachment 111738 [details] Jazz alert example with group 1 color (In reply to comment #22) > @Kimberly: Should we attach the latest UI design for alerts in Jazz to the wiki > topic to give some UI-input? Or is there ongoing exploration in this area over > the next iteration? Ben, all: re-capping a discussion Ben and I had on the alerts topic: Minus a few tweaks to size and animation to be worked out, we have pretty much what we need for Jazz. For those interested in snapshot, I've attached a sample showing a mockup of vista and xp silver themes. The updates reflect discussion in the UIBP about handier location of controls and non-white alerts. Timing-wise, 3.5 will be late for us to take advantage of what the platform provides so for now we will need to move ahead with what we have planned. In the future, if the platform provides some level of framework then we can build on top of that framework later, and hook in our own alerts UI. This is suggesting a UI independent from solution, one which depends on the product using the API. Any UI contributions could then be used or not.
(In reply to comment #26) > Kim Horne: Should we consider a new Platform UI bug on improving tooltips? Or > maybe this is a consideration. On Mylyn are still extending > org.eclipse.jface.window.ToolTip but do a bunch of manual stuff, including > custom multi-monitor and platform-specific handling. Kim: Regarding the tooltips, there are both behavioural and visual things I'd be interested in seeing updated as well. If you open a new Platform UI bug for improving them, I'll add my thoughts there :-) I was planning on opening an enhancement request against jdt/text to address the behavioural aspects but will hold off if this is something that might be opened at the Platform UI level.
(In reply to comment #28) > (In reply to comment #26) > > Kim Horne: Should we consider a new Platform UI bug on improving tooltips? Or > > maybe this is a consideration. On Mylyn are still extending > > org.eclipse.jface.window.ToolTip but do a bunch of manual stuff, including > > custom multi-monitor and platform-specific handling. > > Kim: Regarding the tooltips, there are both behavioural and visual things I'd > be interested in seeing updated as well. If you open a new Platform UI bug for > improving them, I'll add my thoughts there :-) I was planning on opening an > enhancement request against jdt/text to address the behavioural aspects but > will hold off if this is something that might be opened at the Platform UI > level. > I would recommend you log specific bugs for the improvements you want rather than having one umbrella bug to point to. If they're granular enough we can request help from the community...
Removing target milestone since comment 0 starts with "If a generic API for popup notification is created". Bug 229823 asks for such a generic API but is not currently in plan for 3.5.
Created attachment 140815 [details] Growl Proof of concept This is a proof of concept for Growl Notifications : This plugin adds an action which sends raises a Growl notification. This is based on the official Java wrapper for Growl (BSD license). The plugin works on cocoa x86, but fails on x86_64 with this message : java.lang.UnsatisfiedLinkError: /usr/lib/java/libObjCJava.A.dylib: no suitable image found. Did find: /usr/lib/java/libObjCJava.A.dylib: no matching architecture in universal wrapper (Not tested on carbon yet, but according to apple's java package names, this may be cocoa only)
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
would be really great to have Growl support under cocoa 32 and 64, then I could use it to signal if an oaw generation workflow finished
Prakash is now responsible for watching bug in the [Mac] component area.
I think this one can be closed as WONTFIX in favor of bug 497946. Thoughts?
(In reply to Gunnar Wagenknecht from comment #35) > I think this one can be closed as WONTFIX in favor of bug 497946. Thoughts? +1
superseded by bug 497946
