Version: (using KDE KDE 3.2.91) Installed from: Debian testing/unstable Packages Howdi, I use a kicker on the bottom left of the screen, with a size set to 92%. This lets me have two gkrellm's sitting in the bottom right hand corner, side by side. (Gkrellm can only stack multiple displays vertically - so that's why I need to run two btw.) Gkrellm can remember current window positions, stickiness, etc between sessions, and seems to do this okay but for kicker's insistence on moving things around when loading a session. On session start, the location of one of the two gkrellm's is pretty close to where it should be. The other is hidden (the top of it is barely visible). After hiding / unhiding the panel, both of them get shifted up by the height of the panel (90 pixels or so in my case) but retain their respective X coordinates. Curiously after the panel's been un-hidden, the gkrellm's can't be dragged down - they're stuck above that position if you grab their 1 or 2-pixel high drag-bar at the top of their window. But(!) they can be moved part way if you alt-LMB them. Only part-way, mind. They reach a point where they can only be dragged the rest of the way by finding their top-of-window drag-bar. I've got some pics (three x 8kb jpgs) at: http://www.progsoc.org/~jedd/kicker/Index.html (Drop the Index.html if you just want to d/l them directly) They show exactly what I'm talking about .. undoubtedly clearer than the way I've talked about them. Now, this *might* be a bug with gkrellm, but for the fact that anywhere else on the screen and KDE restores them to their rightful place. And, of course, the way that hiding/unhiding kicker causes them to shift. So it seems like it's kicker doing something weird, or expecting not to find anything sharing the space *next* to it (remember it's not actually space that kicker uses in my configuration. It's not a huge problem, since I usually keep my KDE session running for days at a time .. it's more that it's not the way that it should work. Cheers, Jedd.
*** This bug has been marked as a duplicate of 41201 ***
this is a kwin bug now. kicker registers extended struts and is a good citizen in that way. there's nothing more that i know of that kicker has left to do here. passing it on to Seli now that kicker has done its part.
*** Bug 116786 has been marked as a duplicate of this bug. ***
I can confirm that this is still a problem with 3.5.1. Weirdly, just where the pair of gkrellms that I run (both the same height as the panel) start up seems to change every now and then. Usually they appear a few pixels above the bottom of the screen (and extend to a few pixels above the height of the panel). This is just mildly irritating, like being nibbled by a small duck. But sometimes they start up entirely above the panel, directly above where they should be sitting, requiring alt-mouse operations to move then beneath the level of the top of the kicker bar (if you see what I mean). Alt-mouse will only move them to within a few pixels of the bottom of the screen, for some reason, which then requires some pretty neat maneuvering (on a 1600x1200 display) to grab the 'titlebar' of these mini-gkrellm windows, and move them down the next few pixels to the bottom of the screen. This is somewhat more irritating, more like being nibbled by several reasonably sized ducks at the same time.
Hello, I confirm similar bug on 3.5.2 (compiled on debian sarge 3.1r1). I use gkrellm with Dock/panel and Sticky state options. Under icewm it works fine - it starts always on the same position (top-right corner in my case) and kicker panel is full-sized. On kwin it always starts on wrong position (in my case, one its' own window size lefter) and when I move it to top-right corner kicker becomes shorter by this size. When I make up or down some network iface, gkrellm moves again, so I need to move it by hand all the time. Desired behaviour - gkrellm should always start on the position I left it, sholn't move when some changes in its' status appear and kicker shouldn't change its' size.
SVN commit 927466 by lmurray: Improved window movement around struts. Windows can be moved anywhere where the titlebar is still clickable even if it is outside the normal work area. When struts are added or removed only move the windows that cover the same area, leave all others untouched. If a strut is removed on a xinerama screen that is not on the edge of the full desktop area prevent the windows from being moved offscreen. Prevent struts/panels from interfering with the movement of windows on other xinerama screens. BUG: 74559 BUG: 90833 BUG: 160068 M +0 -8 client.cpp M +2 -3 client.h M +301 -142 geometry.cpp M +0 -2 manage.cpp M +20 -0 utils.cpp M +26 -0 utils.h M +4 -0 workspace.cpp M +7 -0 workspace.h WebSVN link: http://websvn.kde.org/?view=rev&revision=927466
You need to log in before you can comment on or make changes to this bug.
KDE Bug Tracking System
KDE Bug Tracking System 