Version: (using Devel) Compiler: gcc 4.3.1 OS: Linux Installed from: Compiled sources In window grid mode, when you drag a window from one virtual desktop to another, the window is drawn only on the desktop where the mouse is, while the second half of the window disappears. Besides, it is impossible to drag maximized windows between virtual desktops.
As a workaround for not being able to move full-size windows you can middle click on the window (which will make it appear on all desktops) and then middle click again on the desktop you want it to be on. The rest is a duplicate of bug 147461. *** This bug has been marked as a duplicate of bug 147461 ***
more infomation in bug #147461
I reopen the bug as a wish as it is something different than bug 147461. As desktop grid is just an animation/representation it would be possible to have the windows overlap several desktops. This is done in cube effect so it should be possible to do this in grid as well. Although I'm not sure if it is a good idea and even if it will be implemented it should be an opt-in.
What the opening reporter is referring to is that while moving a window in desktop grid it should display the window in full, not when it's stationary. In 4.1 this happened but when I rewrote the effect I didn't add the feature because I just couldn't get it working at the time.
*** Bug 179906 has been marked as a duplicate of this bug. ***
I'm not sure if this is just a wishlist and not a bug, because in my installation, the off-desktop windows are actually not displayed at all in the desktop grid.
*** Bug 203107 has been marked as a duplicate of this bug. ***
with 4.4 present windows effect is used by default and by that all windows are shown on the desktop and while moving a window it is attached to the mouse cursor. So I consider this as implemented although the optional old mode is unchanged.
(In reply to comment #8) > with 4.4 present windows effect is used by default and by that all windows are > shown on the desktop and while moving a window it is attached to the mouse > cursor. So I consider this as implemented although the optional old mode is > unchanged. I'm unsure what you mean by that. Is the grid effect still available? If so, what is the behavior of dragging windows through desktops? If not, why? In KDE 4.3 the bug where the window is not displayed at all seems to be gone, but the window is still cut off at desktop boundary. Moreover, this does not only govern the desktop grid effect, but the window is also cut off in "normal" mode. That is, if you move a window in such a way that it overflows your current desktop, you don't see the overflown part on the next one.
I think this blog post should explain it: http://blog.martin-graesslin.com/blog/2009/11/desktop-grid-with-present-windows/
OK, that is an interesting idea. I can see a few pros and a few cons. Is kde 4.4 in at least a beta stage by now so I could try it out? Anyway, that does not solve the question of not seeing a window that is halfway through two (or more) desktops. Maybe it's not that relevant here, tho, so should I file another bug for that?
(In reply to comment #11) > OK, that is an interesting idea. I can see a few pros and a few cons. Is kde > 4.4 in at least a beta stage by now so I could try it out? Beta will be published next Tuesday. > > Anyway, that does not solve the question of not seeing a window that is halfway > through two (or more) desktops. Maybe it's not that relevant here, tho, so > should I file another bug for that? You mean when you are not in desktop grid but normaly using the desktop? That is intended. I would consider that as a serious bug if you would see windows from other desktops in your current desktop.
(In reply to comment #12) > You mean when you are not in desktop grid but normaly using the desktop? That > is intended. I would consider that as a serious bug if you would see windows > from other desktops in your current desktop. Yes. Why would that be a bug? Maybe it could be optional then.
Because: 1. "other virtual desktop" technically means "minimized atm", you'll need compositing and "keep thumbnails for all windows" - what introduces new flaws 2. "other" is clearly different from "this" ;-P The solution is an interim state like "on desktops 1&2" (does kwin support this so far?) but even then you'd rather have to set this explicitly than implicitly (i.e. on all desktops that contain at least 1/5 - to come up with a very naive rule) The reason is that VD are traditionally used to organize your workflow (i.e. e.g. inkscape/browser,mail/IDE/audio,video) and if you switch to the desktop with the IDE you don't want it to be covered by your browser (which you just partially move out of screen to read you mail or whatever) What you're asking for is actually another concept of ONE huge desktop, split into four (or more) tiles (what also implicates a defined geometric order of the desktops - what the VD only loosely provide)
I always thought that VD's were actually just one big canvas on which windows were drawn and one 'desktop' was just one given crop of it. Thus and therefore windows could be asked to render themselves on screen whenever they were at least one pixel within the crop. And I think most window managers, maybe including kde3 kwin did it that way.
There are two different ways to implement VDs: 1. as a large desktop (http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#largedesks) 2. as virtual desktops (http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2505544) KWin implements the second approach and always had. There are only few window managers which use the first approach - must popular probably Compiz.