GNOME Bugzilla – Bug 62652
Sawfish 1.0.1 not behaving with Status Dock/Swallowed Windows
Last modified: 2009-08-16 15:13:28 UTC
In an attempt to upgrade to Sawfish 1.0.1 for the bugfixes, I have found a bug. With 1.0.1, when using the GNOME Status Dock on the panel, it doesn't embed the docklet windows in the dock, sometimes causing them to be the same size as the parent application windows. Also, several empy spaces are created in the dock, though I can't tell what they are for.
Running Red Hat 7.1/7.2 combo with my own mix of Ximian GNOME and Plain GNOME, I can confirm sawfish has major issues with status docklets. It was fine for me in 1.0, but 1.0.1 breaks it.
Any chance this is related to "Swallowed apps don't swallow since Sawfish upgrade from 0.38 to 1.0.1"? http://bugzilla.gnome.org/show_bug.cgi?id=62497
For a nice testcase of this bug I suggest getting the XMMS status docklet from, http://www.hellion.org.uk/xmms-status-plugin/index.html I hope this bug get some attention as it is really annoying
Note that in sawfish CVS the status dock will work *sometimes* -- but I cannot figure out how to determine if it will work or not. More often than not, though, when I initially log into gnome, the status dock won't be working until I try quite a few times. It wouldn't be *as* annoying if the blank spaces weren't left there (which I suspect may in part be gnome panel's fault). I've been trying to look into this without much success. This really needs to be fixed.
The blank spaces are also part of the sawfish problem, they don't occur with the older sawfish. They are due to the fact that the new sawfish isn't handling the winhints properly and it breaks in weird ways. I'm guessing the swallowed app problem is the same, but having never used that functionality, I haven't tried it.
Er, but the older sawfish didn't try to move the window outside the status dock area. I'm saying that maybe the status dock could tell somehow that the window isn't where it's supposed to be and remove the annoying blank spaces.
Some time ago I upgraded both gnome and sawfish, and both the xmms and gabber docklets still failed to be swallowed, although only about once every 10 times. For reference, I'm was on a Celeron 400 CPU, in the event speed is a factor. In the cases where it succeeds, the window can clearly be seen drawn offthe panel first, then moved in. When failing, the window appears to remain at its original location. Moreover, under some system load, ('while true; do ls; done'), the bug appears much more frequently, and the window can actually be seen moving back and forth between being in the panel and elsewhere repeatedly, before settling on one. Sort of looks like a weighted roulette actually. :)
*** Bug 62497 has been marked as a duplicate of this bug. ***
This is not a sawfish bug. The bug is in the docklet protocol.
I've tried different window managers and find that sawfish,icewm, and enlightenment all suffer from this bug, while twm doesn't. This is a big one for me because my whole side panel is supposed to be a swallowed gkrellm for eye candy but it won't swallow. Hope this gets fixed soon (it hasn't worked for me for about 5 months)
*** Bug 73120 has been marked as a duplicate of this bug. ***
*** Bug 67582 has been marked as a duplicate of this bug. ***
*** Bug 52099 has been marked as a duplicate of this bug. ***
If #62497 is a dupe of this one (as John Harper suggests), then the ones I added above are very likely also dupes of this one (I know how the swallow bug looks - seems similar to what has been described for this one).
Federico: is this likely still a bug? Also, should someone from wipro be looking at it?
It is still a bug. I'm not sure what the gnome2 sawfish code is based from, so it may or may not be a problem with sawfish2. There also hasn't been any hacking on this for months, iirc, as I'm not building snapshots anymore. I'm not sure who should look at it, my vote goes for Federico though, but it does need to get fixed soon, and hopefully at least release a 1.0.2 tarball.
The status dock protocol violates the ICCCM and is responsible for the race condition that has lead to this bug report. This is not a Sawfish bug. This should be closed and bugs reports should be filed against the status dock.
Closing as per discussion with greg. He says bug 72594 is the bug he discussed as being the correct bug.
*** Bug 72594 has been marked as a duplicate of this bug. ***
This is not a GNOME 2 bug. The second bug is reported wrong and should be marked as a duplicate of this one. I'm changing the summary of this bug to show that it isn't only status docklets that have the problem, but also window swallowing. If it were a bug in said "docklet protocol", it should only affect status docklets. This is indeed a Sawfish bug. There may also be a "bug" in the fact that the "docklet protocol" violates an ICCCM standard, but either way, this has to be fixed. It's more desirable to violate a standard (they are optional), than to break prior applications by rewriting the entire underlying system for a stable platform.
This is not a sawfish bug. As the window manager, sawfish is responsible for mapped children of the root window that do not override substructure redirection. That includes status docklets and any other such window that is to be swallowed. Both the status docklet and the swallower violate the ICCC in that they cause the a window to transer to an undefined state. The ICCC are not optional. The X protocol is an asyncronous protocol and so care must be taken to avoid race conditions. Both the status dock and the swallower are prone to races. The status dock should use a protocol which does not require docklets to map themselves. Tha swallower will require that applications can receive a message so that they transfer to a Withdrawn state and then may be swallowed.
Here are the results of 'fixing' this in window managers: (1a) Nearly random destruction of application windows (1b) Extra application and X server overhead from 1a (1c) Extra application and X server overhead from fixing 1a. or (2a) Memory leaks in all 'fixed' window managers (2b) Corresponding leaks in the server from window managers using server-side memory (2c) Users finding windows incorrectly placed (2d) Users finding windows incorrectly framed Options: (1) Deal with 1[a-c] (2) Deal with 2[a-d] (3) Port GNOME away from X and any asynchronous protocols (4) Don't use a window manager (5) Use a window manager-based panel and status dock (6) Fix the status dock and app swallowing
*** Bug 65119 has been marked as a duplicate of this bug. ***
*** Bug 71016 has been marked as a duplicate of this bug. ***
*** Bug 76360 has been marked as a duplicate of this bug. ***
Also see the panel version of this bug: http://bugzilla.gnome.org/show_bug.cgi?id=72594
I have just updated my debian woody and seeing that the panel was among updated components, I again tried if the bug persisted: It did not! I was able to have the panel swallow gkrellm. It did not work when gkrellm was already started, but it did, when the panel had to start gkrellm itself. Before the update I found no way, to make the panel swallow any app in any way. I was not able to swallow any other app (other apps are handled differently by the window manager, I think xmms similar to gkrellm, but I don't have it available here for various reasons). I was not able to have a panel swallow gkrellm, when the panel was set to autohide. I had two different aligned panel both have gkrellm swallowed simultainously. The current version of the gnome-panel library, data files and executable packages in debian woody is 1.0.4-6. I don't know the version I had before. Maybe somebody using woody who has not updated could check that? It might only be a new build - all C libraries and the compilers were also updated, also many other gnome components. Sawfish and X were updated a couple of times in the past but not with this particular update. If we can determine which update "fixed" the bug, we might be able to determine where it came from. This might not actually be a final fix to the bug, but it might at least provide new chances for hunting it down.
1.4.0.6-4 is the current version in woody and sid. I still exeperience the docklet swallowing problem on my sid box.
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.
Jeremy: Metacity does not support the status docklet protocol at all, so broken status docklets should be expected. :) On the other hand, it works fine with IceWM.
Okay, well now I'm really confused. If IceWM is actually working properly WRT docklets and swallowed apps, what happened to all the talk of fundamentally broken protocols?
The undocumented protocol is broken in that is is undocumented and that it depends on window manager cooperation. Because of the nature of the bug, it doesn't always appear. If the status dock appears to work with IceWM, that is either because the bug appears infrequently or that window manager supports the protocol. If many IceWM users are KDE users, then it probably has support. (Same holds for other window managers.) Close this bug report. Leave it closed.
It's a sawfish bug. When sawfish is fixed, this bug may be closed. If sawfish is THE gnome window manager, it should support the gnome window hints. If it doesn't it should not be touted as such an application. This bug will stay open until the bug is fixed. If you are volunteering to fix it by suggesting it be closed, then by all means make a patch and attach it to this bug.
> It's a sawfish bug. No. It isn't. > When sawfish is fixed, this bug may be closed. There's nothing to fix. > If sawfish is THE gnome window manager, . . . Other bugs have been already closed because Metacity works. (Metacity does not work with the broken status dock and if you file a report, you'll almost certainly see Havoc mark it as WONTFIX, NOTGNOME, or NOTABUG.) > . . .it should support the gnome window hints. Neither the status dock nor app swallowing use gnome window hints or any documented window hints. > If it doesn't it should not be touted as such an application. The GNOME window hints are deprecated in favor of the EWMH at freedesktop.org. http://www.freedesktop.org/standards/wm-spec.html > This bug will stay open until the bug is fixed. There is no bug to fix in sawfish and there never was. > If you are volunteering to fix it by suggesting it be closed, > then by all means make a patch and attach it to this bug. If you check xdg-list and the desktop-devel list you'll see that I've already proposed a working protocol. A variation of it is on freedesktop.org. The neither my proposed protocol nor the variant requires window manager support. http://www.freedesktop.org/standards/systemtray.html Close this bug report. Leave it closed.
Side note: I see lots of proposed solutions, and deprecated protocols, and plans to fix this in GNOME 2. But GNOME 2 is about to be released isn't it? Isn't this a problem (in _whatever_ package) that should be corrected BEFORE release-time? Furthermore, what about people who will continue using Gnome 1.4? If there's a well-known and documented problem, and one particular software package (icewm) has a fix for this, then sawfish should have a similar fix to ensure that it maintains proper Gnome 1.4 support.
> Side note: I see lots of proposed solutions, and deprecated > protocols, and plans to fix this in GNOME 2. But GNOME 2 is > about to be released isn't it? Isn't this a problem (in > _whatever_ package) that should be corrected BEFORE release-time? If anyone had listened to me when I diagnosed the problem almost a year ago, it would have been long fixed by now. Last I checked, the 2.0 fix was to drop the broken support for the private KDE protocol and just leave support for the private GNOME protocol.[1] > Furthermore, what about people who will continue using Gnome 1.4? The 1.4 versions will need a bug fix to remove the non-CORBA protocol or to use the freedesktop.org protocol. > If there's a well-known and documented problem, and one particular > software package (icewm) has a fix for this, then sawfish should > have a similar fix to ensure that it maintains proper Gnome 1.4 > support. The problem is not well-known. Most people don't know the X or the ICCCM well enough to understand it. The problem is documented in bugzilla and on mailing lists. There is no proper documentation. The way to "fix" it is to discover the protocol (actually, more than one) by reading partial documents and a variety of implementation sources for docklets, window managers, and docks. Another way is to ask the KDE guy responsible to do work for GNOME. After you do that, you will see that there are at least two "fixes" of this nature. One of them is to add support for protocol to Sawfish, the other one is to improve the hack in the status dock which purports (but does not) support the protocol. Neither of these is really fixes the problem; both just sugar-coat it. IceWM may support one or more versions of the KDE protocol. Whatever it supports is a discovered protocol. It does not follow from those conditions that sawfish should do anything for any version. Making sure that GNOME 1.4 works can be done by fixing the status dock - by updating the protocol it uses. The wrong "fix" for the status dock is actually trivial - but it's still wrong, so I won't be the one to say it. [1] There is no fix pending for app swallowing. Without even a proposed protocol, there's no way to fix that. It's another hack that sometimes worked and may have been neat for demo purposes, but was poorly done. If this can be done with a window manager protocol, that protocol is very simple to implement for all apps. But that may not be possible. If it can't be a window manager protocol, it will require application support. At that point, the program may as well be an applet. The same wrong "fix" for docklets applies to this too.
Created attachment 8766 [details] [review] a workaround for the swallowing problem
I've attached a patch against sawfish 1.0.1 which implements a work-around for this problem. It's not a solution, it's not even a fix. It's only a hack, but it works for me and some other people. ;-) You have been warned. There comes no warranty with this patch! It is for all people who suffer from this bug and want a quick solution... How it works: The patch introduces a new option for "matched windows". You can force the old behaviour (i.e. swallowing works as in sawfish 1.0) for the specified window by enabling "Noicccm" (matched windows properties -> State). Sawfish behaves ICCCM compliant for all windows (as in sawfish 1.0.1), except for the "matched windows" with "Noicccm" set.
Hrmm. Interesting. It seems that the problem in sawfish 1.0.1 that I've found is related to the wmspec part of it (the part where it's supposed to have the cooperative wm spec stuff to work with KDE and GNOME). It works fine in 1.0, but the version in 1.0.1 has a lot of changes, some of which, may be the cause of the status docklets issues. I haven't tried your patch yet, because I really don't want to go have to add a bunch of matched window settings to sawfish, and I'm sure all the other users don't either. Anyway, it is a problem in at least the KDE/GNOME cooperative wmspec stuff. (Yes, if something claims to support something, it should support it.)
I'd like to personally report that this patch does not correct the docklet swallowing problem in my case.
Bah. This is just pointless anymore. I filed this bug when 1.0.1 came out. Nobody cares. Nobody wants to fix it. I can't fix it, or I would. I know where the problem is, but still nobody cares. Whatever. This is all tiring and pointless anymore. Sure, GNOME 2 has new status crap, sort of. There is no real example of how to use it effectively. The proposed standards are just that, proposed. They don't fix the behaviour here in gnome 1. Nobody will. Nobody cares to.
What are the odds of getting a fixed docklet in Gnome 1.4 at all? Is anyone dealing with it? From my expeirence with Gnome 2 (especially considering the loss of configuration options, and the lack of a migration tool), I'd guess that there will be many people remaining with Gnome 1.4 for some time after Gnome 2's release. Something needs to be done to fix known bugs & issues at that stage at well.