Re: [MiNT] usage of wind_calc()

[Odd Skancke <ozk@atari.org>]

ons, 29,.06.2005 kl. 23.18 +0200, skrev Arnaud BERCEGEAY:
> Hello,
> 
> >  I have implemented a new 'operating mode' in XaAES, called "Window
> > Coordinate Orientation WORK". There is some documentation about it in
> > newcalls.txt.
> 
> 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 :(

 Sorry if you dont like it. This new model is here to stay, just thought
you'd have some constructive views instead of "will break compaibility"
panics.

> 
> > Please read and give me ideas.
> 
> read... and i still have the same idea about this evolution :(
> 
> > I'm still convinced that
> > usage of wind_calc() should be restricted to its original purpose, i.e,
> > creation of new windows,
> 
> This is not the aim of wind_calc() ! where do you see that ???
> 
> The ONLY aim of wind_calc() is to convert WORK area from/to FULL area for  
> a given AES application (the only contextual stuff is the aes_global  
> array).

 Yes, if we accept that one application never ever in the future can
deal with more than one theme (or even window-type). I dont accept that,
hence WCOWORK.

> 
> > or even completely depreciated.
> 
> So you want to deprecate wind_calc().
> 
> > This work is
> > experimental, and far from perfect, but I seriously think this is the
> > route to take,
> 
> i do not...

 I do.

> 
> > make the FULL extent of a window completely indipendant
> > of the WORK area. That is, applications should only consider its WORK
> > area, and in cases it must know FULL extent for some reason (reasons
> > exists, no doubt) it is 'special case' and for that new wind_calc()
> > prelacing functions exists.
> 
> Why do you want application to use new calls when the AES calls that  
> already exist can do the job ! Ok, standard AES function can't do the job  
> if you deprecate wind_calc(), but i still don't see why you want to  
> deprecate wind_calc(), and i still don't understand why you added this new  
> work feature (i still don't see what these function may be usefull for).

 If you bothered looking at the implementation, you would see that the
only difference between WCOWORK mode and how things work today is this;

 wind_create/wind_open() takes WORK coordinates, no need for wind_calc
(). Only difference here is one less AES call.
 WM_xxx messages contain work instead of full area coordinates,
wind_set/get() works with work areas too. No change in the way things
are handled here, except from cases where the application needs to
modify the new positions. For example snap this is what is needed now;

 1. new_pos = WM_MOVED coordinates
 2. new_pos = wind_calc(WC_WORK, new_pos)
 3. snap(new_pos)
 4. new_pos = wind_calc(WC_BORER, new_pos)
 5. wind_set(handle, WF_CURRXYWH, new_pos)

 Under WCOWORK mode this is done like;

 1. new_pos = WM_MOVED coordinates
 2. snap(new_pos)
 3. wind_set(handle, WF_CURRXYWH, new_pos)

 So you see, the exact same calls are made, just that since the AES also
working with WORK modes instead of with FULL modes, less things are
involved, and most importantly, wind_calc() is not needed. The above
situation is what happens when .. would 99% be too much? .. of the
applications get WM_MOVED. A similar thing exists when servicing
WM_SIZED and WM_REPOSED. 

 Now, there are cases where the FULL extent of a window is needed by the
application. However, this is more like a 'special' case, and only used
when the application wants to do things like automatically layout
(position) windows on screen, etc. In this case, the FULL extent is
needed. And since I still dont want to limit applications to only be
able to handle one geometrics-type windows, wind_calc()s is depreciated
when in WCOWORK mode. Here applications should use wind_xget(WF_CALCx2x)
for the 'special' window handling.

 So, for normal applications, there is no added complexity. Infact there
less complexity because you only need to consider your WORK area.

 For applications that need to autoposition windows, there is one change
only, and that is WORK coordinates need to be translated using
WF_CALCW2F, modified, translated back using WF_CALCF2W. This is exactly
the same amount of work as today, except that wind_calc() is replaced by
wind_xget() calls, so that correct results are guaranteed no matter what
the window's geometrics at the time of the 'window-position actions'.

 In other words; With normal window handling the application only have
to deal with the WORK area of a window. It is no longer forced to work
with two sets of areas for each window. The benefit is less complexity,
and that window geometrics may change at any time without affecting the
application. In situations where the FULL area is needed, there is no
added complexity, just a change in what functions is used. And again,
this is more the 'exception' than the 'rule'.

 
> 
> >  The heavyness of wind_calc() can easily be omitted by caching results,
> 
> Good.
> 
> So, we don't need anything more.
> 
> > but this is not preferred.
> 
> Why ? If some part of the AES needs cache to be performant, then let's  
> implement some cache in the AES ! It's evident IMO.

 I have implemented a cache for this, but with WCOWORK mode it is not
used because reasons said above.

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

 Btw, what is the nature of the WF_TOOLBAR bug?

 Please explain to me why you would need all that to service WM_REDRAW
messages?

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

 It is now reliable, and can be used. However, since this is as 'new' as
the wind_xget(WF_CALCx2x), why not use those instead? Those can
calculate any WORK<->FULL conversions taking into the toolbar. And those
two wind_xget() modes does not change behaviour depening on operating
mode (WCOWORK or not).

> 
> > 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 :)

 Indeed. Will this be taken into account? It is evolution, will add
complexity to support both XaAES (corrected bugs) and still keep code
for buggy AES's.

> 
> >> The goal is to find usefull alernative to wind_calc(), it's not to
> >> deprecate wind_calc().
> 
> I don't understand.

 This is not a statement I made :)

> 
> If you want to find alternative to wind_calc(), it's because you don't  
> want applications to use wind_calc(). In other words, you want to  
> deprecate wind_calc(), no ?

 Yes.

> 
> >  wind_calc() will always be present, but its usage should be depreciated
> > when alternatives exists.
> 
> So you create alternative in order to deprecate wind_calc().

 yes, to be compatible with nolonger supported applications.

> 
> >> The other point is about themes. I see two kind of applications :
> >
> >  And a third one;
> >  - applications like virtual desktop managers, global window cascading
> > applications, etc. These need access to every window's geometrics, not
> > just the ones created by itself.
> 
> 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.
> 
> 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.

 Well, since all AES messages contain WORK area rectangles along with
the fact that wind_set/get() functions all deliver (except WF_CALCx2x
modes, ofcourse) WORK coordinates of windows, WF_CALCx2X is needed in
this case.

 Besides, it would be handy for 3rd kind applications to be able to
place windows by WORK area too.

> 
> Furthermore, the only way an application have to control foreign windows  
> is to send AES messages (WM_MOVED...). But your work option stuff, how the  
> 3rd kind application can know if the foreign application has or not set  
> this WORK option for this window ?

 This is a very good point. How about wind_get(handle, WF_OPTS)?

> 
> 
> >> theme of all windows are updated with the new theme, and so wind_calc()
> >> still returns reliable informations for all window.
> >
> >  I dont see a reason, other than it becoming "complicated" for lib
> > developers to keep all hacks and support XaAES at the same time, to put
> > such a restriction on ourselves.
> > And then there's the third kind of
> > applications....
> 
> I don't see any restriction.

 One application can only deal with windows having the same gemotetrics.
This is a restriction. And it can be removed. Wether or not this is
usable "right now" is another question.

> 
> As see before, the 3rd kind of application is a bad argument.
> 
> The only i see is "wind_calc() must be deprecated", but it's not an  
> argument for me because i still don't understand why you want to deprecate  
> wind_calc().

 I think I once said that "I wont be able to convince them"... 

> 
> >> To sum up, i see no reason why wind_calc() should be deprecated... or  
> >> why
> >> the use of wind_calc() should be forbidden because of themes.
> >
> >  I do. I will keep wind_xget(WF_CALCW2F/WF_CALCF2W) as replacement for
> > wind_calc(), because these will always deliver correct results, no
> > matter what :)
> 
> 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.

 In WCOWORK mode there is only WORK area to consider by applications. In
rare situations wind_xget() will get you FULL area.

> 
> >> The only think i see about about wind_calc() is that it's a heavy
> >> function, and so we may try to replace wind_calc() by something else in
> >> speed-critical subroutines. In all cases, the values returned by
> >> wind_calc() are still reliable.
> >
> >  Reliable long as the values returned are not applied to an existing
> > window. For your two application type above, you 'maybe' right (maybe,
> 
> not 'maybe' : it's sure.
> 
> If it's not sure, then wind_calc() shall never be used and whall be  
> removed from the AES right now !

 Dont be an idiot.

> 
> > because we dont know what the future brings, if anything). But for the
> > 3rd kind of applications this is very false.
> 
> not agree. 3rd kind of application is a bad argument.

 No, its not.

> 
> > I want to remove this
> > problem, and try to do it so that such problems are gone forever.
> 
> 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...

 That is your opinion.

> 
> 
> >> For REQ1, as wind_calc() always works (even if it's a slow function, it
> >> works), then applications can keep using wind_calc() to compute FULL  
> >> area
> >>  from wanted WORK area.
> >
> >  This is what I want to change.
> 
> Why ?

 See above.

> 
> Because wind_calc() should be deprecated if i get you... but why do you  
> want to deprecate wind_calc() ?

 See above.

> 
> > With WCOWORK mode, wind_open() accepts
> > WORK coordinates (and thus no need to use wind_calc()).
> 
> I see... now, instead of using wind_calc() from time to time, applications  
> will have to use wind_xget() with new modes to do the same job ! an this  
> is window dependant ! The kind of computation and functions to call  
> depends on the window handle !

 Yes.

> 
> I really don't like at all this evolution.
> 
> Furethemore, i think this is incompatible with windom (i don't want to  
> support an XaAES only branch of windom... which will be much more complex  
> that the "common to all AES" branch)... So we'll have to add a "please  
> never use the XaAES WORK feature" in windom documentation... I think it's  
> ok for everyone because the WORK feature doesn't help the developper.

 Here we have the reason we never get anywhere in a nutshell. Please
dont introduce new features, it makes my life hard. Goddamned, I'm tired
of this.

> 
> >  Yes, evolution sucks, eh?
> 
> No, only bad evolutions ;)

 Well, the only real reason I get from you 'added complexity' supporting
this in WinDom. So, I think that this is a fight I will be having for
every new feature I add. Too bad, this situation.

> 
> i want evolutions, but good one : evolution that are usefull.
> 
> > I think this is necessary to 'move on'.
> 
> Yes but move to somewhere; not move around to do the same stuff with other  
> incompatible functions.

 wind_calc() is context-less, wind_xget(WF_CALCx2x) is context
dependant. Big differance. Furthermore, WCOWORK is a new operating mode.
A new way for applications to consider its windows. One that will take
out complexity. Ofcourse, supporting both solutions in the same app will
add complexity. But that is a thing I cannot consider. This is a 'new'
feature, and makes XaAES application authors life easier.

> 
> > I
> > will go forward with this, and see what happens.
> 
> If it's the way you want to discuss... it's fine :(

 I'm tired of being told that 'new' features add complexity. I mean,
wind_get(WF_WORKXYWH) cannot be used under other AES's, but under XaAES.
I dont see a complexity-difference wether you use wind_xget() or
wind_get() here. Either can only be used on XaAES (as of now) anyway!

> 
> > I refuse to let old
> > bugs in no-longer-supported AES's stop XaAES.
> 
> 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.

 See the previous paragraph.

> 
> > If this is not
> > appreciated, now is the time to make a separate 'n.aes==xaaes' source
> > tree.
> 
> I don't get you there.

 I you want to make sure XaAES goes nowhere, now is the time to fork the
source tree into two separate branches. One that never goes past what
n.aes supports, and one that I can continue work on. Because I wont let
this stop me doing new things.

> 
> >> For example, at the moment, when an application receives a WM_MOVED
> >> message, then the application calls wind_set(WF_CURRXYWH) with  
> >> buff[4..7]
> >> as parameter. This is automatised in windom : most of windom  
> >> applications
> >> don't care about such messagesn all is managed by windom... but the
> >> application can take control of such event if needed.
> >
> >  So, operating in WCOWORK mode you can still do that, because WM_MOVED
> > then contains WORK area coordinates, and wind_set(WF_CURRXYWH) is the
> > same as wind_set(WORKXYWH). This means that for the rare occasions where
> 
> Ok, i won't tell you to read the whole window source code. This is just an  
> example, and the problem is still there. When windom will call  
> wind_set(WF_CURRXYWH), then maybe the parameters will be taken as FULL  
> area, or as WORK area... windom don't know because windom don't know if  
> the application has done a WF_OPT or not before for this window.

 Why would windom need to know in the first place?

> 
> >> In fact, the very main reason against the proposal is that it add
> >> complexity in developpement... and what's for ? What's the requirment ?
> >> Why the need for this option ?
> >
> >  For applications that try to work on all AES's this adds complexity,
> 
> Even if you want to make a windom for xaaes only this will add complexity.

 No, it wont. In that case the lib would use WCOWORK mode by default.
And the application author would know. The lib would be a LOT cleaner,
because all hacks could be taken out.

> 
> > agreed. But I do not think the complexety is great.
> > Try experimenting
> > with it, and see how easy it actually is.
> 
> Overall, i still dont understand the aim of this complexity : what's the  
> marvelous feature hidden by all these new functions ? I still only view  
> complexity and incompatibility issues only. No gain at all.

 First of all, there is no added complexity. The added complexity you
talk about is the extra code needed to figure out what AES, and act
accordingly, needed for applications that want to support it all. The
solution itself (WCOWORK) is actually less complicated. Now, this added
complexity will be a "problem" for each and every 'new feature' that is
developed. I dont want to listen to such arguments.

> 
> Last note: all this is because of the "on-the-fly" theme change if i get  
> you right... a feature that should not add any complexity to application  
> IIRC :/

 And it wont. Just go with the old version, and dont support XaAES
directly and it will be a single-theme application. If you want to use
the new feature WCOWORK, all such restrictions are lifted. 

> 
> 
> best regards,
> Arnaud.
> 
> 
> PS : If all goes right, i'll be offline ( short holidays, but holidays  
> :)).... right now. I'll be back online 4th july. Don't expect an answer  
> until then.

 Have a good vacation :-)

Best Regards
Odd Skancke