Re: [MiNT] WM_REPOSED implementation

[Odd Skancke <ozk@atari.org>]

lør, 10,.12.2005 kl. 13.43 +0100, skrev Jo Even Skarstein:
> > -----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 ;-)

 I'm gonna tell you a little secret :) XaAES actually already, and have
always, send a new x/y in SIZED messages when top/left or left borders
dragged. If you look at the code, you will discover that both the
WM_SIZED/WM_MOVED pair sent contains the EXACT SAME rectange! What I
should perhaps try is to send the SIZED first before the MOVED.

> 
> >  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.

 Yes. And this is the main argument that comes my way each time I try to
do something new...

> 
> > > 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.

 This _became_ the right method by the introduction of resizing by
top/left, left window borders. Prior to that, SIZED meant a change in
the window size only and no change in position. I agree that if window
geometrics where described by x1/y1,x2/y2 things would be different. But
its not. Windows are described as x/y/w/h. I think it is a good idea to
keep SIZED to mean only that window size changed. When windows are
resized by top/left border, this is a resize. But its not ONLY a resize
n the sense that both x/y and w/h changed.

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

 In a perfect world, no ;-) But we are definately far from being in a
perfect world. What we have to consider is how applications up to XaAES
looks at SIZED/MOVED messages. I see no reason to change this.

> 
> > 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.

 This could have been the only difference, yes. But many apps dont see
it that way.

> 
> > 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? ;-)

 evnt_multi() tells me exactly what I want to know, that I can wait for
multiple events ;-)

> 
> >  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.

 Is Geneva still being supported? I have never actually tested it..

> 
> 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.

  3. Send WM_SIZED first, so that the WM_MOVED doesnt make a difference
when apps treat WM_SIZED 'correcly', and avoid configuration variable.

> 
> 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.)

 They will be. That is, only thing that remains is to implement a
'control center' via which such things can be configured.



 Best Regards,
Odd Skancke