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

[Danesh Dadachanji]

Hi Anthony,

On 26/10/11 08:56 AM, Anthony Petrov wrote:
> Hi Danesh,
>
> On 10/25/2011 10:00 PM, Danesh Dadachanji wrote:
>> On 24/10/11 08:49 AM, Anthony Petrov wrote:
>>> While you're at it, there's just been filed a bug report:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7103610
>>
>> WM_CLASS is already set to something relative to what is being run.
>> E.g. when using xprop on a Frame
>> $ xprop
>> WM_CLASS(STRING) = "sun-awt-X11-XFramePeer", "test-TestFrame"
>>
>> Reading the specs of WM_CLASS[1], I think the above is incorrect. I
>> believe "test-TestFrame" makes more sense as the first st ring, the
>> instance name.
>>
>> As for the second one, from my understanding of the spec, you would
>> want it to be set to something more generic that. Do you think "Java"
>> is a better option?
>
> I agree that the strings might be in the inverse order currently, and it
> would be nice to have them in the correct order. There's some sense in
> using the "sun-awt-X11-XFramePeer" however, since it may be used to
> distinguish between apps run using the XToolkit, and legacy MToolkit
> (removed in JDK7, but still available for apps run with JDK6 and
> earlier). If in the future we introduce some alternative AWT toolkit,
> then having the toolkit name in the string might be useful.
>
> Having said that, I don't think we should change the value of the
> property. There's two reasons:
>
> 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).

> 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.

>>> which suggests that the mentioned window properties need to be set on
>>> all application's windows, not just the tray icon window. What do you
>>> think about extending this logic to all windows? We could add a method
>>> in the XWindowPeer class for this, and install the properties on all
>>> windows (including the tray icon - since it's an embedded frame that
>>> uses the XEmbeddedFramePeer as its peer).
>>>
>>
>> If all app windows need to be set, wouldn't this mean all X components
>> as well? In which case, how does adding the code to XBaseWidnow
>> (looking specifically at init) sound?
>
> I don't think so. The window properties are used by the window manager
> (mostly). The window manager will never see our child windows, and as
> such setting the property for them seems useless.
>

Oh right, I'll stick to XWindowPeer then.

>>>> 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?

Thanks for the comments.

Regards,
Danesh