Re: [MiNT] usage of wind_calc()

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Wed, 2005-06-29 at 23:18 +0200, Arnaud BERCEGEAY wrote:

Let me step in between you guys.

> I like very much the way XaAES moves... You ask for comments, and then you  
> implement your original idea without taking into account comments. It's  
> good :(

I've seen this happen on other projects.  Its not a bad thing though
since in this case, it won't affect anything but new apps that decide to
test the new code.  Its merit can then be determined.

> >  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.  First, I don't know of any bug in
WORKXYWH unless you mean that the toolbar is included in the working
area of the window.  That may be considered a bug and it might not.
I've not dealt much with toolbar programming, and I assume attaching the
toolbar allows the AES to handle the redraws.  It also means that any
features like "detachable toolbars" cannot be done solely by the AES
because of this "bug" and that applications would have to know more
information.  In this case, its easier to just handle the whole toolbar
yourself, and then you don't have to worry about which AES version you
have either.  I never liked the whole toolbar issues.

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?

> If we know that wind_get(WF_WORKXYWH) is reliable, then for sure we can  
> use it. A bit in appl_getinfo (the bit that indicates  
> wind_set(WF_WORKXYWH) is available) may be used for that purpose too.

Reliable?  When is it not reliable?

> > Furthermore, WM_REDRAWs, at least in XaAES,
> > never deliver coordinates outside a window's WORK area.
> 
> so wind_get(WF_WORKXYWH) is bug-free in XaAES :)

Again, I fail to see what the area given to redraw in the WM_REDRAW
message has to do with wind_get(WF_WORKXYWH).   And again, even if the
redraw area was outside the window - which I don't see as a bad thing -
a dialog box going away might send the REDRAW message with the rectangle
of that dialog to all windows under it - the application shouldn't care
since when you walk the rectangle list, the extra area outside the
window gets factored away.

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

> So, this 3rd kind of application is out of the scope of the wind_calc()  
> discussion. We cannot argue about wind_calc() by using this 3rd kind of  
> application.

Agreed.

> But with wind_get(WF_WORKXYWH) and wind_set(WF_WORKXYWH), the convertion  
> between WORK and FULL area are no more usefull... except before creating a  
> window, and there wind_xget() could not be used.

Agreed.  And that is the mostly likely time to require such a function.
After that, the usefulness of knowing the relationship between WORK and
FULL area is less likely to ever be needed.

> I don't see any problem ! I still don't understand what all your new  
> features are for ? To add complexity for developpers, yes i see that :/  
> it's the only purpose i've found up to now...

I believe the idea is to introduce a newer model of operation with more
flexibility and more features that is less prone to having issues in the
future.  I don't think that this is a bad thing, and I definately think
it warrants some discussion.

I don't think the proposed change is quite enough to be as far-reaching
as ozk intends, nor do I think enough discussion has happened in regards
to what future enhancements will be and how to best support them.  A new
model may be fine, but I don't want to see something new done now, and
then make a third and a fourth "enhancement" that breaks how messages
are intepretted and such.  If we change something that important, lets
make sure we only do it ONCE!

Communicating only the working area is a start.

> The only bug that forced windom to use wind_calc() so often is  
> wind_get(WF_WORKXYWH), and this is now fixed, so there is no more pending  
> bug related to our discussion.

Still lost on this one.