GNOME Bugzilla – Bug 72594
Problems with gnome docklets from 1.4 applications
Last modified: 2004-12-22 21:47:04 UTC
Can somebody review this bug, reported as related to sawfish, but which has recently been suggested as a bug "in the docklet protocol"? http://bugzilla.gnome.org/show_bug.cgi?id=62652
It is suggested in the other bug that this is G2, but I can't duplicate it myself, perhaps because I'm not quite sure what the problem is.
I'm not using gnome 2, if that's what you were suggesting. The problem is that gnome status docklets are sometimes not swallowed by the status dock. The behavior does not appear to be consistently reproducable... You can enable & disable to a docklet 100 times, and it might be swallowed properly 20 times, or 80 times. It seems to vary somewhat with system load, implying some kind of race condition. It's been observed by some people in the bug I referenced under several different window managers. It's most easilly reproduced with Gabber (a gnome Jabber client), by opening the preferences window, and repeatedly selecting & unselecting the "Display GNOME/KDE status docklet" checkbox.
Just for the record, this is not only a bug in panel 1.5.x, it is also in panel 1.4.x :(
*** This bug has been marked as a duplicate of 62652 ***
Reopening as per greg's request. [Note to all parties: I'm not making a judgement on the correctness of greg's request; just doing this since he doesn't have permissions.]
Okay... so I guess that means the first issue is figuring out where this bug goes, whether with sawfish or gnome... The discussion over at <a href="http://bugzilla.gnome.org/show_bug.cgi?id=62652">62652</a> has been getting stale...
*** Bug 16230 has been marked as a duplicate of this bug. ***
I recently tried, and can reproduce this bug in enlightenment 0.16.5.
For one reason or another, I'm not able to reproduce this problem with icewm 1.0.9.2. Using twm on the other hand presents an interesting situation, because it's default action of using the mouse interactively to place windows occurs. After selecting the window position, the docklet is swallowed immediately.
Update: This bug appears to be very easy to reproduce using metacity as the window manager. Whether this is the fault of a bug on metacity's part, or a particular suceptability to this bug, I can't tell.
It is just that the docklet protocol is broken/not agreed on/etc. It doesn't comply with ICCCM I've been told. This should really be marked NOTGNOME. Someone should write up a spec for the docklet protocol and make sure it's sane across dekstops / WMs etc.
Okay, well, taking it as a given that this bug isn't going to be corrected for quite a while, is there anything that could be done to slow the bleeding? If it's a race condition like most people are suggesting, is there somewhere a "sleep" could be put to at least influence the probability that the docklets will be swallowed correctly until a real fix is in place?
IceWM plays nicely with docklets and the gnome 1.4 panel.
Anybody familiar enough with IceWM to tell us whether we're simply evading the race condition by luck/hack, or if there's actualy been some concious effort to get around it there? If there's a possibility that this can actually be properly addressed on the window manager side, even if only as a temporary measure, it'd be appreciated.
Ok, GNOME 2 is getting closer and this needs to be resolved somehow as the panel dock is still a part of the GNOME2 ui. This used to work in Sawfish so it can be resolved from the windowmanager side even if a by doing some hack, the redesign of the protocol is already beeing looked at at freedesktop.org AFAIK, but that is for the future. Question is what to be done now?
*** Bug 17764 has been marked as a duplicate of this bug. ***
*** Bug 62648 has been marked as a duplicate of this bug. ***
Bug 62652 is also a duplicate of this bug, but I am not sure which to mark as duplicate of which as both contain some usefull information about the problem.
There's a draft spec for the system tray on freedesktop.org and an initial implementation in CVS as system-tray-applet. There is no way this will make GNOME 2.0.0 though. The "status docklet" applet in CVS now should be disabled in 2.0.0.
Any roadmap for the new system-tray's adoption into gnome-proper? I don't foresee any developers targetting Gnome2 as their platform will consider writing code for this until a reasonable number of Gnome2 users can be expected to have an implementation of the system-tray spec.
The system-tray applet has been proposed for addition to GNOME 2.2. Do we still need to leave this bug open ?
I think the new tray always sucessfully swallows. It has some other issues, like making icons the wrong size and putting them in the wrong place, but those are separate bug reports. ;-)
The only reason I can see this bug to remain open is as follows: Gnome 2 generally has the ability to run Gnome 1.4 applications, because all the libraries are not mutually exclusive. Unfortunately, Gnome 1.4 applications still don't have any means to reliably get an entry on the dock. What could be done to enable Gnome 1.4 developers to write software that would work with the Gnome 2 system tray reliably? The one I spoke with was put off of the idea of support here because the API for getting onto the Gnome 2 tray was not available to 1.4 applets, therefore requiring him to drop down to a lower level, managing hints directly. Even if applications can't natively support both the 1.4 and 2.0 system-trays, I suspect a compile-time option on their end might at least allow applications that won't get ported to participate in the freedesktop spec. This justification works for me, so I'll re-open under this modified summary, unless someone wants to mark it as WONTFIX for 1.4.
The system tray protocol has completely changed. This is very similar to other incompatibilities between 1.4 and 2.0 (e.g. you can't use 1.4 applets on a 2.0 panel). I think adding support for the old protocol would be a mistake. Marking as WONTFIX.
I'm not suggesting that the system-tray-applet get support for the old protocol. I'm suggesting that developers of gnome1 applications need a slightly-higher-level way to use the new protocol, since it appears to be very awkward for the time being: Julian Missig wrote: > Yes, I'm aware of the system tray, however, that's for gnome2 and is > not easy at all to implement using gtk1. The system-tray is after all only there to implement the freedesktop.org spec. Surely it's still important for Gnome1 applications to have access to this protocol?
It would be a ton of work to add this. One of those things where if someone wants to do it great, but I doubt it will make it to the top of anyone's priority queue before it becomes irrelevant over time.