Hi Anthony,
On 11/1/2011 7:52 PM, Danesh Dadachanji wrote:
1. The WM_CLASS property is used to look up X resources for the app.
Java apps (and AWT itself) have never used X resources, and as such it
actually doesn't matter at all what is specified in these property.
Perhaps I've misunderstood this but are you saying "it actually
doesn't matter" for java apps or for the WM? I understand how it
doesn't make a difference to java apps themselves but I don't think
that's correct for the WM. In the case of GNOME3, it requires this
property to be set in order to group similar apps (it didn't need the
property in the past).
Do all Java windows get grouped together in Gnome 3 even if they belong
to different applications now? Doesn't setting the _NET_WM_PID help a WM
differentiate between the apps?
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.
2. Some developers may rely on the current order of the strings if they
want to look up Java windows from their native apps, for example. If we
change the order now, we may break these use cases. While the order has
never been specified, I don't see a good reason for this change at this
time.
Yes it probably would be best not to change this then. We should
mention it on the bug report though.
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".
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.
Regards,
Danesh
[1] http://icedtea.classpath.org/~ddadacha/tray_icon/
