18 messages in net.java.openjdk.awt-devRe: <AWT Dev> [RFC] Tray icons for ap...| From | Sent On | Attachments |
|---|---|---|
| Danesh Dadachanji | Oct 20, 2011 1:02 pm | |
| Anthony Petrov | Oct 21, 2011 4:43 am | |
| Anthony Petrov | Oct 24, 2011 5:49 am | |
| Danesh Dadachanji | Oct 25, 2011 10:59 am | |
| Anthony Petrov | Oct 26, 2011 5:56 am | |
| Danesh Dadachanji | Nov 1, 2011 8:51 am | |
| Anthony Petrov | Nov 1, 2011 1:52 pm | |
| Danesh Dadachanji | Nov 8, 2011 1:52 pm | |
| Anthony Petrov | Nov 9, 2011 3:53 am | |
| Danesh Dadachanji | Nov 9, 2011 9:06 am | |
| Anthony Petrov | Nov 11, 2011 4:28 am | |
| Danesh Dadachanji | Nov 15, 2011 1:12 pm | |
| Anthony Petrov | Nov 16, 2011 4:25 am | |
| Omair Majid | Nov 21, 2011 10:18 am | |
| Anthony Petrov | Nov 22, 2011 5:58 am | |
| Dalibor Topic | Nov 22, 2011 6:10 am | |
| Omair Majid | Nov 22, 2011 11:00 am | |
| Anthony Petrov | Nov 22, 2011 11:55 am |
| Subject: | Re: <AWT Dev> [RFC] Tray icons for applications are not displayed in the GNOME notification bar. | |
|---|---|---|
| From: | Anthony Petrov (anth...@oracle.com) | |
| Date: | Nov 9, 2011 3:53:22 am | |
| List: | net.java.openjdk.awt-dev | |
Hi Danesh,
On 11/9/2011 1:53 AM, Danesh Dadachanji wrote:
Windows are grouped by application and the WM recognizes the same applications based on WM_CLASS, not _NET_WM_PID. I'm not entirely sure about the best way to deal with Java applications, do we consider each Java app as an individual app or do we treat them as one - they are being run via 'java' after all. I would have guessed the latter, letting developers specify otherwise. Take Eclipse for example, WM_CLASS is set differently than the default so it isn't being grouped with other Java windows.
The way Eclipse behaves makes sense to me, actually. Since WM_CLASS should contain two strings - an 'app class' id and an 'app instance' id - I'd have guessed that 'java' (or, rather, 'sun-awt-X11-XWindowPeer') might be a good candidate for the 'class' id. And a string that identifies a particular app instance might be, for example, the PID of the JVM the app is running in.
Opinions?
Given that JDK 8 is currently at its early stage, and that the probability of such dependency is somewhat low (besides, a particular order has never been documented and/or specified), we might actually try and reverse the order of strings in the WM_CLASS property and see if everyone's fine with this change. In the worst case, we can always reverse it back, I guess. After all, this is not the most important part of the fix.
I was going to request this be backported to JDK 6 and 7 once the patch for JDK 8 was approved. Would it be better to create a separate patch for this and only apply that to JDK8? From what I can tell, they're pretty independent in terms of code.
Also, I don't think just reversing it will be enough, you'd have to set the second string to something generic like "Java".
I agree, making this change as a separate fix sounds reasonable. Please feel free to start a new thread on this mailing list and send the fix for review.
You're right. The 'awt' directory contains mostly legacy and shared code from the (now retired) MToolkit era. I think that the already existing XToolkit.c in the xawt directory should be just fine for our purposes. Looking forward to seeing a patch.
Great, I've updated XToolkit.c with the native code and the webrev[1] with the new patch.
The fix looks very good. Thank you! Just a few stylistic remarks:
In src/solaris/native/sun/xawt/XToolkit.c 1) Please move the #include statements in the beginning of the source file. 2) The JNI methods are supposed to have comments just before their declarations, listing their Class, Method names, and its Signature. Please see examples of such comments in the XToolkit.c file. 3) Native code uses slightly different code conventions than Java code, and, in particular, we prefer to put the opening curly brace on a new line after the function prototype. 4) Also, on the line 1108 please put a space between "if(" so that it reads "if (". 5) We use 4 spaces to indent blocks of code.
Once this is done we'll be able to integrate the fix in JDK8.
-- best regards, Anthony