David Reveman wrote: > On Sat, 2007-05-19 at 17:35 +0100, Mike Dransfield wrote: > >> David Reveman wrote: >> >>> On Sun, 2007-04-29 at 15:17 +0100, Mike Dransfield wrote: >>> >>> >>>> Jesper Andersen wrote: >>>> >>>> >>>>> Replying to my own email here: >>>>> >>>>> On Fri, 2007-04-27 at 09:05 +0200, Jesper Andersen wrote: >>>>> >>>>> >>>>> >>>>>> I am using the lastest git version of compiz and just run in to a new >>>>>> problem after switching to using the ini configuration plugin over the >>>>>> gconf-one. When I maximize a window and then try to move it to another >>>>>> viewport, the cube rotates but the maximized window disappears instead >>>>>> of moving along to the new viewport. The maximized window can be found >>>>>> using the scale plugin (only on show-all action). Further, if I then try >>>>>> to unmaximize the window, the window again disappears and I have to use >>>>>> scale's show-all action. Now, however the window appears in some random >>>>>> almost out of viewport location and I have to drag it back into >>>>>> position. >>>>>> >>>>>> I do not know whether it was my switch to the ini plugin that caused >>>>>> this annoying change in behavior. >>>>>> >>>>>> >>>>>> >>>>> I now tried with either gconf and ini (with the same settings) and >>>>> nothing changes. However I noticed the following: whenever I move a >>>>> window with some contents below the bottom edge of the screen to another >>>>> viewport, it is immediately displaced on the new viewport so that most >>>>> of the window's content is above the top edge of the screen. How much >>>>> seems related to how much was hidden below the bottom edge before the >>>>> move (this is only when moving a window to a new viewport by >>>>> <Alt><Shift>Left/Right and similar, not for the usualy mouse-dragging of >>>>> windows and also not for windows that are beyond any other screen >>>>> edges). I have tried toggling the "Constrain y" option in the >>>>> move-plugin to no avail. I also tried changing the "detect outputs" in >>>>> the general options, also to no avail. >>>>> >>>>> I am not sure when this strange behavior was introduced and I am >>>>> wondering whether I am really the only one seeing this? >>>>> >>>>> >>>>> >>>>> >>>> No you are not. >>>> >>>> I can see both of these problems now and I have tracked the >>>> problem down to the moveWindowToViewportPosition function >>>> OR the w->output.top calculation. >>>> >>>> The exact line is this one >>>> >>>> if (m - w->output.top < w->screen->height - vHeight) >>>> >>>> In the case I just tested this variables had these values. >>>> >>>> m = 20 >>>> w->output.top =23 >>>> >>>> w->screen.height and vHeight are both 1050. This if statement >>>> returns true because -3 < 0 and it shifts the window down. >>>> >>>> Sorry, I am not sure how to best fix this one but it is a reproducible >>>> problem. >>>> >>>> I also see the offset problem as well and suspect its related to the >>>> same thing. >>>> >>>> >>> It should now be fixed. Thanks for tracking this down, Mike. >>> >>> >> I can still see a problem when moving windows across viewports >> when they are off the top of the screen. >> >> To reproduce, put window off the top of the screen and then use >> <ctrl><alt><shift>Right to move with it. The window gets put >> off the bottom of the screen. This is in a typical 4X1 arrangement >> with cube and rotate. >> > > How about now? >
Yes, that seems to have got it, thanks. > -David > > _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
