Re: [MiNT] usage of wind_calc()

[Odd Skancke <ozk@atari.org>]

 Hello,

man, 04,.07.2005 kl. 22.35 +0200, skrev Arnaud BERCEGEAY:
> 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 a new operating mode! What do you mean AES messages are no
longer unifersal?

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

 Yes. Altho this is not the most important argument. The point is that
when something new is to be implemented, one may try to get rid of as
many restrictions as possible.

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

 This is open for discussion.

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

 How about letting wind_create() return the real maximum (modified input
coordinates)? Remember, we're not trying to be compatible with this new
operating mode, so new thinking is allowed!

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

 Have you ever tried to snap a window containing text using the fonts
with/heigh? Have you ever looked at Qed source? Have you ever seen
Everest? You tell me how else to snap coordinates!

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

 yes, if no modification, like snapping, is needed.

> 
> There is no need of wind_calc() !

 Get your facts right!

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

 You are wrong.

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

 There is a call wind_get(WF_FULLXYWH/WF_PREVXYWH). Those buggy in other
AES's too? Anyway, these are the ones to use for the above. WF_FULLXYWH
will get you the maximum size of the window, as set/modified by
wind_create(). XaAES also have wind_set(WF_FULLXYWHY/WF_PREVXYWH), so
application dont really have to track this for itself (untested tho).

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

 Why?

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

 So use wind_set(WF_FULLXYWH). I think ALL applications have wind_get
(WF_FULLXYWH/WF_PREVXYWH). Why are those not used?

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

 Own modifications, you are correct. But even then WCOWORK will help,
because after the application knows the new image size (which is the new
WORK coordinates), there is no need for wind_calc() to convert to FULL
for wind_set(WF_CURRXYWH). So, WCOWORK will help!

 And, again get your facts right, this is not the only situation where
WORK coordinates need modifications!

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

 wind_get(EF_WORKXYWH) will always return WORK area, agreed. But all AES
messages dealing with window coordinates should be trusted! The AES will
make sure that WM_SIZED, for example, contains WORK area coordinate even
if the sending app is not WCOWORK.




 Best Regards,
Odd Skancke