<AWT Dev> [RFC] Tray icons for applications are not displayed in the GNOME notification bar.
ddadacha at redhat.com
Tue Nov 8 13:53:01 PST 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?
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
>>> 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.
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
with the new patch.
More information about the awt-dev