Re: [MiNT] WM_REPOSED implementation

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Thu, 2005-12-08 at 20:59 +0100, Arnaud BERCEGEAY wrote:

> With "old" AES, there are two messages :
> 
> - WM_MOVED when the window is moved. Only x/y coordinates may change.
> - WM_SIZED when the window is resized by the "sizer" widget which has 
> always been on the bottom/right corner of the window. With WM_SIZED 
> message, only w/h data may change (never x/y).

Uhmm ... which documentation says that only the XY will change on
WM_MOVED and that a WM_SIZED message will never change XY?

What is documented is that the message contains the new coordinates of
the window - it doesn't say anything about what may or may not change in
the message.  Since the OS gives you XYWH, and you need to call wind_set
with exactly these same parameters, it doesn't make any sense to not use
the data the OS just gave you.

WM_SIZED and WM_MOVED both report the new XYWH of the window.  You
respond with:
	wind_set (msg[3],WF_CURRXYWH,msg[4],msg[5],msg[6],msg[7]);

So, if resizing by a window border or non-standard corner, just send the
WM_SIZED message, since WM_SIZED handling for the application may
contain additional code for a repaint of the window or something.  Does
any application actually ignore the x & y coordinates that the OS gives
it in the WM_SIZED message?   That just seems like a really stupid thing
to do.

> Now, if the AES allows the user to resize a window by using a border or 
> any corner of the window, then when you resize a window all the fields 

I had forgotten about the left and top borders since I always use the
right or bottom borders (or adjacent corner).  Whoops!  Must be brain
damage.

But .. isn't this still just a WM_SIZED?

> xywh may change, and there's no AES message for such case... until ozk 
> invented WM_REPOSED :)

I don't see a reason for yet ANOTHER message that should be handled
justy like WM_SIZED.  How is this different from WM_SIZED?  And when do
you send WM_REPOS and not WM_SIZED?  This is fragmenting the API even
more and I really don't see any benefit.

Now .. I would also encourage everyone to update internal structures
when you get an AES message and then set a 5ms timer on evnt_multi()
when you need to do actually update a window, reposition it, redraw it,
etc.  In most cases, no one notices the 5ms delay, but it allows your
application to handle messages much faster and not get behind since you
won't ever try to update the display as long as more events are pending
that could re-update it.

I do this in javascript (a window and menu library for the web) quite a
bit, using timer events to do any screen updates, since you can get huge
floods of messages when trying to do any sort of javascript mouse
tracking (dragging windows and menus around, animations, drop-downs) and
periodic updates make for a much more visually pleasing interface.