Hi Danesh,
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?
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.
There's no any guarantees regarding the format of the string returned.
Which means that if the XToolkit code is going to be run with a VM
other
than, say, Hotspot, the method may return a differently formatted
string, and hence this code may fail.
Is there a more robust way to obtain the PID and the client FQDN?
For the PID, I think using JNI to access getpid() would be the next
best option. I'll look for another way to find the FQDN.
Yes, using getpid() via JNI seems reasonable. I guess gethostname() from
unistd.h might be used to obtain the FQDN.
While running a standalone java app with JNI, both of these worked fine
for me so I think this should be reasonable.
I'm not sure of the conventions for native code but it doesn't seem that
useful to create a new file just for 2 (rather small) functions. Any
suggestions as to which native file I could modify by adding these
functions? I looked through src/solaris/native/sun/xawt/ but I'm not
sure which file is ideal. If adding a new file is more preferred then,
just to clarify, it should go into the above dir (as opposed to awt),
correct?
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.
--
best regards,
Anthony
