Re: [MiNT] usage of wind_calc()

[Odd Skancke <ozk@atari.org>]

tir, 05,.07.2005 kl. 08.25 +0200, skrev Arnaud BERCEGEAY:
> Sorry for the repost (if any?)
> 
> ------- Forwarded message -------
> From: "Arnaud BERCEGEAY" <arnaud.bercegeay@free.fr>
> To: "Evan Langlois" <Evan@coolrunningconcepts.com>
> 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