Re: [MiNT] WM_REPOSED implementation

[Odd Skancke <ozk@atari.org>]

tor, 08,.12.2005 kl. 17.28 -0600, skrev Evan Langlois:
> On Thu, 2005-12-08 at 23:29 +0100, Odd Skancke wrote:
> 
> >  XaAES sends new X/Y (and keeps W,H as was) when sending WM_MOVED
> > (because per definition MOVE means exactly that, and thus W/H should not
> > change), and sends new W/H, keeping same X/Y for WM_SIZED. Why? Because
> > per definition SIZED means window was resized, not MOVED.
> 
> Per definition, its you message number 27 which is sent when someone
> drags a window and message number 28 which is sent when the window is
> resized.  Both send the new window coordinates to the application.
> 
> Per definition, SIZED means 27 only because your header file defines it
> that way.  I can use case 27: and case 28: if I want.  I can use #define
> WM_EVANGELIZED 27 and call the message WM_EVANGELIZED if I want.

 And what is your point here? I have been looking for the documentation
in which I read what I state above about the convenience of the message
containing both coordinate pairs. Cant find it, ofcourse. Well, let me
try to explain again;

 WM_MOVED - the window has move, only its X/Y coordinates have changed.
You dont need to do extra checking on this fact if you need to snap your
window's X/Y. Likewise, W/H have not changed, you dont need to check
that either if you need to snap your windows W/H.

 WM_SIZED - The window has been resized. Only its W/H coordinates have
changed. No extra checks to see if window moved because per definition
it didnt move with this message, (if you need to know) or no extra need
to check if it changed size, because if it didnt you would not receive
this message.

 WM_REPOSED - The windows X/Y and W/H both changed. You need to consider
both coordinate pairs, again you dont need to access your windows's
private coordinates to compare against message coordinates to figure out
move/size or a reposition. (ok, reposition is when X/Y changes
indipendant of W/H, but I didnt find a better word).

 Now you can just feed the coordinates received in the messages to
wind_calc() then to wind_set().

> 
> >  To catch the situation where both coordinate pairs (X/Y AND W/H)
> > actually CHANGED, WM_REPOSED was invented. Lets not give new meanings to
> > ancient stuff, please. The W/H in WM_MOVED are for convenience only, not
> > expected to change. X/Y in WM_SIZED are also for convenience only, not
> > expect those to change. Its in the goddamned name of the goddamned
> > messages!!!!
> 
> You are being unreasonably stupid here.  You are making definitions of
> your own interpretations and not even following them.  If you resize
> with the size widget, it should send a WM_SIZED, but if you move the
> window its WM_MOVED, and if you resize with the window border its ...
> 
> wait .. is it always WM_REPOS?  Is it WM_REPOS only if the X or Y
> change?  Will it send WM_SIZED if X and Y stay the same?

 Yes.

> 
> Applications don't care what your compiler header file defines things
> as.  It just knows that when message 27 or 28 comes in - the window has
> new coordinates.  You should likely check to see if width or height has
> changed in both cases and take appropriate action, however, the little
> sample "lazy method" works as well.
> 
> There is no reason for the AES to send two different messages other than
> historically, each widget usually sent its own type of message.  Doing
> this would only slow things down and cause the exact problem you want to
> remove with WM_REPOSED.
> 
> Let's not cause new problems.  Its long been documented that all 4
> coordinates are returned as part of the message.   In your owns words,
> "Let's not give new meanings to ancient stuff"  Resizing a window with
> the upper left corner should send a WM_SIZED, not a MOVED and then a
> SIZED, or a REPOSED which only bloats the API even more!

 Read above about the messages. Also, if I find the place where it says
that both coordinate pairs are always found in the messages is for
convenience only I will post it. So, resizing by a windows upper left
corner should send a pair of WM_MOVED/WM_SIZED or a WM_REPOSED.

 Ofcourse, you could use WM_SIZED as a WM_REPOSED, if thats what you
mean, but this would lead to extra code in each application to check if
only a size or both a move/size happened .. and for what? One extra
messgage definition in your compiler header file?

 This is the last time I comment on this, because its not gonna change
in XaAES anyways.




 Odd Skancke