[compiz] Bug with kde applications and damageWindowRect wrapping...

[David Reveman]

On Thu, 2007-04-19 at 19:52 +0200, Danny Baumann wrote:
> Hi,
> 
> > - add-place-window-proc.diff
> > 
> > This line in the place plugins placeWindow function:
> > 
> > if (!w->placed && !w->attrib.override_redirect)
> > 
> > should be removed. The "if (!w->placed)" check should be moved to
> > event.c so the patch will look like this:
> > 
> >                 applyStartupProperties (w->screen, w);
> > 
> > +               if (!w->placed)
> > +                   (*w->screen->placeWindow) (w);
> > +
> >                 w->pendingMaps++;
> 
> Done in the attached one. 
> 
> > I also think it makes sense to make PlaceWindowProc look like this:
> > 
> > typedef void (*PlaceWindowProc) (CompWindow *window,
> >                                  int        x,
> >                                  int        y,
> >                                  int        *newX,
> >                                  int        *newY);
> > 
> > as it allows the core to eventually apply that position change as part
> > of some other configure request.
> 
> I have made PlaceWindowProc return Bool to indicate if the window was
> actually placed or not (and thus newX and newY are valid).

I think we want to have w->placed be set to TRUE in event.c even though
the call to PlaceWindowProc returns FALSE. Good otherwise, please commit
it.

> However, I still have one question: How can core determine if the
> position change can be applied later or must be applied straight away?
> Because that isn't clear to me yet, the attached patch still does
> moveWindow() and syncWindowPosition().

That's fine for now. We can improve it later on by making it possible to
send any stack/size changes that should be made before the window is
mapped in the same configure request.

> 
> > - place-fix-decoration.diff
> > 
> > Yes we need this change but there's missing break statement before "case
> > MapRequest:". I know it was missing before this change too but it didn't
> > cause any harm then.
> 
> Yes, obviously ... thanks for spotting that. I will commit it (including
> the break; ;-) ) together with the other one once it's ready.

Good.

Thanks,

- David