Re: [MiNT] usage of wind_calc()

[Odd Skancke <ozk@atari.org>]

 Hello,

 I have implemented a new 'operating mode' in XaAES, called "Window
Coordinate Orientation WORK". There is some documentation about it in
newcalls.txt. Please read and give me ideas. I'm still convinced that
usage of wind_calc() should be restricted to its original purpose, i.e,
creation of new windows, or even completely depreciated. This work is
experimental, and far from perfect, but I seriously think this is the
route to take, 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.

søn, 26,.06.2005 kl. 21.57 +0200, skrev Arnaud BERCEGEAY:
> Hello,
> 
> We agree on a lot of things, but for some points it seems that we don't  
> understand each other... and this discussion tend to become a big soup  
> with all and nothing inside. I think it's time to make a point.
> 
> I'll try to sum up once again :)
> 
> ok, the main sensitive point is that wind_calc() may be a heavy function  
> in some AESes, and so we have to find how we can use others AES functions  
> to  do the same thing for critical pieces of code, i mean piece of code  
> executed for WM_REDRAW messages for example. The piece of code that create  
> a window may use wind_calc(), it's not critical.

 The heavyness of wind_calc() can easily be omitted by caching results,
but this is not preferred. 

 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), and
wind_calc() cannot take into account a toolbar (because of its lack of a
window context, thus impossible to know about toolbars). This means that
neither of these calls can be used to account for a toolbar anyway.. or
am I missing something? Furthermore, WM_REDRAWs, at least in XaAES,
never deliver coordinates outside a window's WORK area.

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

 wind_calc() will always be present, but its usage should be depreciated
when alternatives exists.

> 
> The other point is about themes. I see two kind of applications :
> 
> - applications that cannot handle on-the-fly change of theme (typically,  
> old applications) : here, if the user changes on-the-fly the theme of the  
> AES, then the AES will keep using the old theme for that application, even  
> for window opened after the change. This is needed because such  
> application may have memorised border size of window (computed from  
> wind_calc).
> 
> - applications that can handle on-the-fly change of theme. Here, if the  
> user changes on-the-fly the theme of the AES, then the AES will change the  
> theme for all already opened windows, and for window that will be open  
> later too of course.

 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. Impossible with todays wind_calc()
combined with evolution.

> 
> Do we agree on this ?

 Well.. apparently not :-)

> 
> If so, then for a given application, all the windows of that application  
> use the same theme. So, when an application invoke wind_calc(), then the  
> value returned is reliable for all the windows already opened, and well as  
> for window that will be open in the futur... Of course, such value must  
> not be memorised because it may become out dated if the theme changes. But  
> if the theme change, for application that support change of theme, the  
> 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....

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

> 
> 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,
because we dont know what the future brings, if anything). But for the
3rd kind of applications this is very false. I want to remove this
problem, and try to do it so that such problems are gone forever.

> 
> Please tell me if we agree on that.

 Sorry .. cannot do that.

> 
> I make the hypothesis that we agree, and i'll try to find why wind_cal()  
> is used at the moment. This is the list of requirements hereafter :
> 
> >> REQ1 : the AES shall provide to the application a way to open a window
> >> with a given WORK area position/size

 Yes.

> 
> >> REQ2 : the AES shall provide to the application a way to change the WORK
> >> area position/size of a window (AES will change the FULL size of the
> >> window in consequence)

 Yes.

> 
> >> REQ3 : the AES shall provide to the application a way to get the WORK  
> >> area
> >> position/size of a window.

 yes.

> 
> We saw that if AES provides wind_get(WF_WORKXYWH) and  
> wind_set(WF_WORKXYWH), then REQ2 and REQ3 may be fulfil without using  
> wind_calc().

 Yes! ;-)

> 
> 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. With WCOWORK mode, wind_open() accepts
WORK coordinates (and thus no need to use wind_calc()). 

> 
> 
> So no further modifications are needed.

 If only thing were that simple :)

> 
> If you want to change something else, it's because you have some other  
> requirements for applications, and please list them.

 Right now the only one that springs to mind is the type 3 apps
mentioned above. But I'm sure there are other restrictions I cant think
of right now my approach will remove...

> 
> >  Ok, now I will explain the idea I have now, which came from a comment
> > you made above; Applications only know about the WORK area of windows
> > they use.
> 
> No. Please remove the "only" word and i agree. The point is that  
> applications NEED to know about the WORK area, but applications also NEED  
> to know about the FULL area.

 Well.. yes. But this is more seldom than not.

> 
> For example, when a window is full-sized, application may set the window  
> to the whole screen, and for this, the only way is to work with FULL area.  
> Another example: an application is a drawing application, and it has a  
> vertical tool window on le left of the screen - when the image window is  
> opened, the application open it to cover the whole screen except the tool  
> window, and to do that, it have to work with FULL area of windows. Another  
> example: an application provide a way to re-organize the windows  
> (mosaique, cascade...) : all this is a work on FULL area.

 Yes, and when the re-organizer is a global one, wind_calc() cannot be
used at all. For this wind_xget(WF_CALCx2x) will solve all problems.

> 
> Application should be able to work on both FULL and WORK area... but hey!  
> wind_get/set(WF_WORKXYWH) and wid_get/set(WF_FULLXYWH) both exist ! AES  
> already provides all we need.

 Indeed. Altho most of the time, applications are happy knowing the WORK
area ,-)

> 
> > If we remove the need to convert WORK coordinate to FULL and
> > vice versa, wind_calc() would not be necessary.
> 
> True because this is the aim of wind_calc() ;)
> 
> But if you follow me, the goal is not to deprecate wind_calc() even for  
> new applications. I don't see any reason to do that...

 I definately see ... if not many as in a list of app-types, etc., the
need to depreciate wind_calc().

> 
> About you suggestion to work on WORK area for all the wind_xxx stuff, i  
> really don't think it's a good idea. Comments hereafter :
> 
> >  Implementation suggestions;
> >
> >  For new applications that detect WORK area oriented windowing by
> > checking appl_getinfo() the following is done;
> >
> >  wind_set(-1, WF_OPTS, 1, WO0_WCOWORK, 0, 0)
> >  (WindowCoordinateOrientationWORK)
> >
> > This will turn the AES into "application only gets WORK coordinates"
> > mode, and affects the following things;
> >
> >  WM_MOVED, WM_SIZED, WM_REPOSED, WM_ICONIFY, WM_UNICONIFY, WM_ALLICONIFY
> > contain WORK area coordinates instead of FULL coordinates.
> 
> I don't like this proposal because that will create another way to treat  
> these messages.

 Yes, evolution sucks, eh? I think this is necessary to 'move on'. I
will go forward with this, and see what happens. I refuse to let old
bugs in no-longer-supported AES's stop XaAES. If this is not
appreciated, now is the time to make a separate 'n.aes==xaaes' source
tree.

> 
> 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
the applications needs to work on FULL area coordinates, wind_xget
(WF_CALCW2F) is needed to convert to FULL, do the work on the
coordinates, then wind_xget(WF_CALCF2W) to convert back to WORK for
wind_set(). For normal operation, where it is the WORK area that is of
interest, no need to convert anything. Just pass directly to wind_set()

> 
> What i try to say is if a windom applications choose this option, then the  
> developper will have to write its own event handler for all the messages,  
> because windom won't be aware of this option.

 Too bad, then.

> 
> 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,
agreed. But I do not think the complexety is great. Try experimenting
with it, and see how easy it actually is.

 For XaAES (or AES's that support this XaAES sceme) only apps, this
sceme will make it significantly easier ... and it will make that app
work for all eternity, giving XaAES developers freedom ;-)

> 
> All i see is that wind_get/set(WF_WORKXYWH) solve all our problems, and  
> wind_calc() remains here for the only case it is needed (convert WORK to  
> FULL area for wind_open).

> 
> 
> Ok, there's some points that we didn't discussed yet about  
> wind_set(WF_WORKXYWH)... will discuss them later when we agree on the main  
> solution (only wind_get/set are needed).

 I dont know if that will ever happen ;-)


 Best Regards
Odd Skancke