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

Re: [MiNT] usage of wind_calc()


 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"

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

 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,