Re: [MiNT] WM_REPOSED implementation

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Sat, 2005-12-10 at 18:38 +0100, Jo Even Skarstein wrote:

> Not so sure about this. If you send SIZED first, then the application
>  might crop the window if the new width and height exceeds the limits
>  of the screen. When the window then is moved, you'll not get the desired
>  effect. I think it should be moved first, then resized.

I'd be angry if an application did this with my window.

MOVE first is likely to look better visually, SIZE first has the problem
that if the application tries to crop it, AND you make it bigger from a
border AND the application ignores the XY in the SIZED message ... thats
a lot of conditions! ... then the window will stay small and move.

The alternative of not having to send a MOVE when SIZE is handled is
much better than always moving a window before resizing it which means
every application would behave oddly - correctly written or not.

> And as I just wrote in my previous mail, when you send the second
>  message, you need to use the new and correct geometry as set by
>  the application following the first message. Sending the same 
> rectangle in both messages will mess things up if the application changes
>  the position or width/height (e.g. cropping to an AES object tree or
>  snapping to a grid).

Yes, thank you!  Finally someone that agrees that the second message
should be sent after the app calls wind_set(), not at the same time as
the previous message.

> >   3. Send WM_SIZED first, so that the WM_MOVED doesnt make a difference
> > when apps treat WM_SIZED 'correcly', and avoid configuration variable.
> 
> See above, this might not work.

That works more often than not.  Clipping windows to the screen seems
bad to me.   

If someone wants that, the AES should do it, not individual
applications ... hmm .. If the AES had a "Clip Windows to Screen"
option, and you dragged a window off the edge of the screen, I wonder if
that would send a MOVE or a SIZE ... hmm ... a MOVE with the WH
changing!!!  LOL!  YES!!  Send the MOVE, and if the application doesn't
respect the WH, send a SIZE to fix it.  I found a case where a MOVE can
change the WH!!  LOL!

Anyway, back to reality.  Your MOVE-first plan would always cause the
window to jitter when resizing by a border, unless the new WH were
included and the application respected them, and I see less chance of
that happening than respecting the MOVE.  This could cause extra
repaints all over the screen.  I'm thinking it would cause more
problems.