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

[Anthony Petrov]

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