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

[Danesh Dadachanji]

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/