<AWT Dev> [RFC] Tray icons for applications are not displayed in the GNOME notification bar.

Anthony Petrov anthony.petrov at oracle.com
Wed Nov 9 03:53:45 PST 2011


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.
> 
> [1] http://icedtea.classpath.org/~ddadacha/tray_icon/

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



More information about the awt-dev mailing list