From mint-bounce@lists.fishpool.fi Tue Jul 5 17:00:37 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] usage of wind_calc() From: Odd Skancke To: MiNT List In-Reply-To: References: <42BB46F0.4090206@chello.nl> <1119599743.15790.284.camel@linuxbox> <1119718803.15790.339.camel@linuxbox> <1119779027.15790.442.camel@linuxbox> <1120071508.19330.55.camel@linuxbox> <1120086064.11804.57.camel@taro.coolrunningconcepts.com> Content-Type: text/plain Date: Tue, 05 Jul 2005 16:57:32 +0200 Message-Id: <1120575452.5673.54.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit 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=-0.7 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: tir, 05,.07.2005 kl. 08.25 +0200, skrev Arnaud BERCEGEAY: > Sorry for the repost (if any?) > > ------- Forwarded message ------- > From: "Arnaud BERCEGEAY" > To: "Evan Langlois" > Subject: Re: [MiNT] usage of wind_calc() > Date: Mon, 04 Jul 2005 22:35:37 +0200 > > because wind_get(WF_WORKXYWH) is buggy in some AESes : with buggy AES, > wind_get(WF_WORKXYWH) forget to take into account the height of the > toolbar. > > The method in windom works for all AESes. > > The "clean" method (use wind_get(WF_WORKXYWH)) fails with some AESes. How many AES's have this bug? Only N.AES? > > Now, if the AES is able to tell the application that wind_get(WF_WORKXYWH) > is bug free -- and we can use the new bit for wind_set(WF_WORKXYWH) for > this purpose -- then windom will use wind_get(WF_WORKXYWH) instead of > wind_calc() even if it's not trivial in windom. This is now present in XaAES (see newcalls.txt). Let me know if this is a decent solution. > > I though we all agreed on this subject, and the discussion was over on > this subject. Yes, the toolbar matter is closed, if the appl_getinfo() implemented in XaAES is OK for all :) > > > you won't ever get a rectangle outside the working area. When do you > > need to know WORKXYWH for a redraw? > > Well, at least to know the where is the top left corner of the work area > (the origine of the drawing for the window). > > The redraw message doesn't always concern the whole work area. Right. For that wind_get(WF_WORKXYWH) should be used. Instead, as a hack to overcome AES shortages, wind_calc() was used. And here started the wind_calc() discussion ;-) > > >> Ok, let's talk about these kind of application. They may want to control > >> over foreign windows (windows owned by an other application). Such > >> application does not need to know anything about the "work" area of > >> foreign windows. The only information that may interest such application > >> is the FULL area of foreign windows. wind_calc() is never usefull here. > > > > I agree here. There "applications" don't exist, and quite a bit of > > discussion should happen to detail how they should operate before we > > just assume too much about them or make decisions that affect all > > applications for the sake of something unwritten. > > Agreed. Even if I agree here, we should make sure 'this' discussion wont create problems later. I want to avoid that 'this' creates limitations for things we want to do 'later'. I dont want to do 'that' for 'this' assuming 'that' will never be an issue 'later'. I wonder if that made sense to anyone ;-) > > BTW, just two words about this. The idea is to allow an application to > change size & position of foreign window (window owned by another > application), right ? I see only two ways to do that : > > 1. by using AES messages : the application sends WM_MOVED (for example) > message to the other application, and the other application (which owned > the targetted window) changes the position/size of this window. This is the only method of modifying window position of windows owned by other applications. > > 2. by using remote control mechanism, for example GEMSCRIPT commands : the > application sends commands ("open file.txt", "move_window file.txt" for > example) to the other application, and the other application will execute > the commands received. Much like the way AV_PROTOCOL works? > > The 1st solution works for all applications (even to control windows of > old applications). It's the universal way, but the application has to know > internal stuff of the foreign windows. For example, if you want to control > the window of a text editor where the file "file.txt" is edited, then the > application have to know the AES window handle of this foreign window, > which is not so evident. I dont see the problem here. What exactly is the hard part? > BTW, with the WORK stuff in xaaes, this will no more work, because the > content of WM_MOVED messages depend on choices make by the application for > this window. This is not true. The AES will make sure the application gets the correct data. > Without this WORK stuff, we have an unified interface for messages, wich > is good. With this WORK stuff, you state that WM_MOVED & co messages could > no more be used between applications. When did I state that? This is a job of the AES, to make sure the clients get the correct data. > > The 2nd solution is the cleaner and powerfull solution, but it requier the > support of GEMSCRIPT command in applications. > > Last, i don't see why the new wind_xget() modes (replacement of wind_calc) > are usefull for such application : an application is not able to invoke > AES function on window owned by another application ! (i hope i read too > fast somes posts and misunderstood) There are certain data about windows that is accessible (read only) by any application indipendant of window ownership. These include window positions, state (ontop/untop/shaded/iconified, etc) and a few other things. What is not possible is for foreign apps to modify any of these things. So to do that, the relevant WM message is used. > > I'm still lost with the new features you added... The only point i see is > still the broken compatibility and the worst is that standard AES messages > (WM_MOVED...) is no more universal and could no more be used between > applications, or between an application an a high library (windom for > example). Then that library should not be used with WCOWORK mode. As simple as that. Best Regards, Odd Skancke