Re: [MiNT] usage of wind_calc()

["Arnaud BERCEGEAY" <arnaud.bercegeay@free.fr>]

Hello,

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

the fact that AES messages are no more universal, which is my "will break  
compatibility" panic, is a very constructive argument that should be taken  
into account IMHO.

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

Things are clearer now : you want to deprecate wind_calc() because you  
want application to deal with several themes.

Let's make this the new starting point (even if i don't agree on your  
target): the required stuff is functions to replace wind_calc(), with the  
handle of the window as argument because now the WORK<->FULL computation  
depends on the window.

Your new wind_xget() functions is the good answer.

WCOWORK is not related at all to this problem. IIRC, the only aim of  
WCOWORK is to easy the life of the programmer (arguments later on this  
subject), but WCOWORK is definitively not an answer to the "theme per  
window" stuff.

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

Let's talk about wind_create() : what's the data to put in the function ?  
At the moment, most application put there the WORK area of the desktop,  
because it's the maximum value of the FULL size of the window.

Now, this is the maximum size of the WORK area of the window ? Before it  
is created ? So we cannot use wind_xget(WF_F2WXYWH). The only solution to  
create a window is then to use the deprecated wind_calc() function ?

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

I don't agree at all ? Do you do such nasty stuff in your own applications  
?

I think in most "not so bad" written AES applications we have the  
following:

1. reception of WM_MOVED/WM_SIZED message
2. apply the new position : wind_set(WF_CURRXYWH,data of the message)
3. get the new WORK area (WM_SIZED) : wind_get(WF_WORKXYWH)
4. update the slider stuff

There is no need of wind_calc() !

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

With WCOWORK, it's the same :

1. reception of WM_MOVED/WM_SIZED message
2. apply the new position : wind_set(WF_CURRXYWH,data of the message)
3. get the new WORK area (WM_SIZED) : wind_get(WF_WORKXYWH)
4. update the slider stuff

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

So, this is something that most applications usually do. When the user  
clic on the FULL widget, then the application set the FULL area of the  
window to the WORK area of the desktop :  
wind_set(WF_CURRXYWH,handle,desk.g_x, desk.g_y...).

With the WCOWORK stuff, the application will have to call wind_calc() or  
its replacement wind_xget(CALC) for such standard event !

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

I don't agree.

For all AES messages (WM_SIZED, WM_MOVED...), this mostly deal with FULL  
area (and not WORK area).
For example, when the user clic on the full widget, the user commands to  
the application "set the FULL area of the window to the whole screen".

The modification of WORK area by application is only needed when the  
content of the window has a particular defined size (for example formular  
in window, image viewer...). This is not related to AES messages. Such  
modification occured on other events (drag'n drop of an image in the  
window for example, open of a formular...). The WCOWORK solution won't  
help at all.

BTW, in all cases, application should always gets WORK area from  
wind_get(WF_WORKXYWH) and not trust the AES message: this message may be  
sent by another application, or replay by an event recorder/player, and so  
the value in the message may be different to the real WORK area once  
wind_set() has been applied by the AES.

best regards,
Arnaud.