From mint-bounce@lists.fishpool.fi Sat Dec 10 00:38:08 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <1134171157.439a141589d71@imp1-g19.free.fr> Date: Sat, 10 Dec 2005 00:32:37 +0100 From: Xavier Joubert To: MiNT List Subject: Re: [MiNT] WM_REPOSED implementation References: <1134166727.439a02c7bec16@imp1-g19.free.fr> <1134168954.439a0b7a48c89@webmail1.utbm.fr> <1134169484.29437.97.camel@linuxbox> In-Reply-To: <1134169484.29437.97.camel@linuxbox> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 84.4.181.33 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: xavier.joubert@free.fr 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.2 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 jB9Nc7mY005630 Hi Olivier, Hi Odd, Selon Odd Skancke : > A million ways to do this and achieve some kind of result. What I have > got now works, so why not use that? Hmmm. Why create a new message when you can work with existing ones ? ... Perhaps because, as Olivier showed, handling this with existing messages is not as easy as it first seemed (to me, at least). > > In your case I know application that don't like it, for example Qed and > windows > > dialog in Windom, and there is other, I test only some softwares. > > In case of Qed, with WM_SIZED it will change with and height to have a mod8 > or > > mod16 for this value, and recalculate sliders, then you put WM_MOVED with > width > > and height you wan't but not new width and height that application wan't, > Qed > > will put it directly but not change his size nor recalculate slider, this a > > very small problem in fact. For Windom case this is stronger because > position > > will be good but size can be totaly wrong, because on WM_MOVED it not look > for > > new size, so if window is bigger than dialog, other part of window will not > > redraw at all, because it correct size only on WM_SIZED. So prefer WM_MOVED > > before WM_SIZED. Thanks a lot for your explanations Olivier ! And what if an application tries to snap window position (ie. X and/or Y) to 8 or 16 pixels, as did "tempus word" in the old ST times ? I guess your method will have the same troubles as mine. Such applications are just far less common in real world... > And all of these problem are solved by the method I use in XaAES. Now that I see problems I didn't even envisage before, I guess your method is not so bad. Well, it even looks like the /right/ way to handle this... The theorical "good way to handling" something often doesn't survive "real world". :) Best regards, Xavier