From mint-bounce@lists.fishpool.fi Sat Dec 10 15:48:13 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] WM_REPOSED implementation From: Odd Skancke To: MiNT List In-Reply-To: References: Content-Type: text/plain; charset=utf-8 Date: Sat, 10 Dec 2005 15:44:19 +0100 Message-Id: <1134225859.29437.143.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=1.7 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: * Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id jBAEmDLw027154 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