From mint-bounce@lists.fishpool.fi Thu Dec 8 22:25:20 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] WM_REPOSED implementation From: Evan Langlois To: Arnaud BERCEGEAY , mint@fishpool.fi In-Reply-To: <43989091.3000906@free.fr> References: <4397F4C3.7030701@utbm.fr> <1134069883.19887.135.camel@taro.coolrunningconcepts.com> <43989091.3000906@free.fr> Content-Type: text/plain Date: Thu, 08 Dec 2005 15:23:42 -0600 Message-Id: <1134077022.19887.178.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.fi X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com 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=2.1 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: ** 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.