Re: [MiNT] WM_REPOSED implementation

[Jo Even Skarstein <joska@online.no>]

> -----Original Message-----
> From: mint-bounce@lists.fishpool.fi
> [mailto:mint-bounce@lists.fishpool.fi]On Behalf Of Odd Skancke
>
>  Since there has been no way to size a window in a way that affects both
> coordinate pairs, this is what applications are actually expecting. I
> didnt add sending a pair of WM_MOVED/WM_SIZED just for the fun of it. I
> did this because almost every app I tried needed this. Thing was one of
> the few exceptions.

OK, this is what I wanted to hear, it has actually been tested ;-)

>  Even if I am wrong about this, keeping the 3 different messages wont
> hurt, will it? XaAES will at least follow these rules until someone can
> convince me it is a bad thing to do. And comments wont work, I want
> evidence :)

REPOSED will hurt in the sense that it adds even more complexity to
AES-coding. Instead of just handling SIZED correctly, you now have to check
specifically that this mode/message exists! I suspect that not many coders
will use this to solve a minor cosmetic issue. It doesn't make any sense to
me, I really can't see how this new message can solve any problems.

> > I'd say that the obvious solution is to just send a correct
> WM_SIZED message
> > when a window is resized with the top and/or left border, and I
> suspect that
> > this will work correctly with most applications. In those cases that it
>
>  This is just not correct. Try to uncomment the ...
>
> if (move)
>    send_moved(lock, wind, AMQ_NORM, &r);
>
>  ... part in size_window() in widgets.c and see how it works.

Well, I don't have GCC/etc on my Milan so I can't compile anything.

> > intended. Nothing is lost - but all applications that interpret WM_SIZED
> > correctly will work perfectly. No need to send both SIZED and
> > MOVED-messages, no new mode/message to support.
>
>  This would make it necessary for EVERY application in the system to
> contain code to detect which coordinate pair actually changed, in which

No!! The correct way of handling a WM_SIZED message is...

1. Retrieve the message with the new geometry (x, y, w, h).
2. Modify the geometry if necessary (e.g. if you like your windows snapped
to a grid).
3. Set the new geometry with wind_set(x,y,w,h)
4. Retrieve the new geometry as set by the AES with wind_get.

It doesn't matter if only one or all four values are changed.

> case we could replace all three window size/position messages with only
> one. I dont think this is a good tradeoff. Two messages are already

No, you can't. WM_MOVED doesn't change the width and height of the work
area, so you don't need to recompute sliders or contents. This is the only
difference between WM_MOVED and WM_SIZED, but it tells you what you need.

> defined. Together with the possibility to resize windows by upper/left
> or left borders comes a new message that indicates both coordinate pairs
> changed. XaAES will still send WM_MOVED/WM_SIZED when only one of the

Which WM_SIZED already does. I have never seen any official or semi-official
statements that says that WM_SIZED only modifies two of the four boundaries
of a window.

> coordinate pairs changes. WM_REPOSED is sent only in the circumstances
> where both coordinate pair changes. And then the message names actually
> makes sense to newbies, jsut as they did when I was a newbie.

10 letter (including a 3 character prefix) names can never tell the exact
specification of a constant, variable or function name. Only documentation
does that. The name "evnt_multi" doesn't teach you how to handle events,
does it? ;-)

>  This wont change, so lets drop this now, unless there are concrete
> examples of this being a bad, bad implementation :)

See above.

>  most things can be configured on a perapp basis in XaAES :)

Good! This is my favourite feature of Geneva, it can be configured to the
extreme for each applications. This allows both badly written (in the sense
that they take short-cuts or violate AES specifications) software to be run,
as well as letting properly written software take full advantage of Geneva.
Geneva is even shipped with a database with recommended settings for lots of
applications.

To solve this WM_SIZED/MOVED/REPOSED issue I suggest the following approach:

1. By default, send WM_SIZED whenever a windows has been resized, regardless
of which parameter has been changed. I.e. just send the new x, y, width and
height of the window.
2. Make it possible to disable this on a per application basis. E.g. a
keyword called "no_smooth_resize" or something similar that tells XaAES to
send first WM_MOVED with the new position, then WM_SIZED with the new
geometry.

This way all applications - new and old - that handles WM_SIZED correctly
will work properly, while applications that makes assumptions will work by
configuring XaAES.

(BTW. for something like this to work smoothly XaAES all per-app options
must be configurable on the fly.)

Jo Even