<AWT Dev> [RFC] Tray icons for applications are not displayed in the GNOME notification bar.
anthony.petrov at oracle.com
Tue Nov 1 13:53:16 PDT 2011
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
> 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
>>>>> 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),
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.
More information about the awt-dev