[compiz] Maximized windows dissappear

[David Reveman]

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?

-David