[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] usage of wind_calc()

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


Let me step in between you guys.

You're welcome :)

>  I think I need a new explanation of why wind_calc() is necessary to
> service WM_REDRAWs again. There is a bug in wind_get(WF_WORKXYWH).

Yes, an so, the only way to get the WORK area is to :
- get the FULL area
- convert FULL to WORK area (well, work area without TOOLBAR)
- remove "by hand" the height of the TOOLBAR to get the real WORK area of
the window.

Wait - why is ANY of this needed.

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

The method in windom works for all AESes.

The "clean" method (use wind_get(WF_WORKXYWH)) fails with some AESes.

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.

I though we all agreed on this subject, and the discussion was over on
this subject.

However, why do you need WORKXYWH to handle a redraw?  You are given a
rectangle that needs to be redrawn, which shouldn't be outside the
working area of the window, but even if it is, when you walk the
rectangle list and merge those rectangles with the area to be redrawn,
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.

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.


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.

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.

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.
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.
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.

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)

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

best regards,