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
