[MiNT] usage of wind_calc()

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

Hi list,

I just read a lot of very true things in this list regarding wind_calc(),  
and its usage in windom and xaaes. I'll try to sum up ideas and add my  
point of view.

About windom, most applications use the stable version of windom (release  
1.21.3, branch windom-1-21-stable-branch in CVS). The main branch in CVS  
contains the futur thread safe version of windom (will be release 2.0.0).

The main point is that wind_calc() cannot be set as deprecated. It's the  
only relevant way to take control over the work area of a window  
(including already opened windows). Here are some examples :

* if one wants to open a window with the left side at a particular  
x-coordinate (16 pixels alignment ?), then wind_calc should be used to  
convert the WORK area to the FULL area, because wind_open() expects the  
FULL area as parameter.

* if one wants to open a window with a particular width and height  
(formular in window, or image viewer...), then wind_calc() should be used  
to compute the FULL area expected by wind_open().

* the usual way to change the size of a window is by using  
wind_set(WF_FULLXYWH). I'm sure that some AESes are not able to handle  
correctly wind_set(WF_WORKXYWH). So, if one wants to change the size of  
the work area of a window, wind_calc() is the solution. You want an  
example usage for this feature ? Well : adjusting the size of the work  
area to the new loaded image for an images viewer, or dynamical adjustment  
of width and height of formular (with formular dynamically built with DFRM  
for example)...

* about wind_get(WF_WORKXYWH), this may not always work : some AES are  
buggy and don't count the height of the toolbar... and so we have to do it  
by hand (get FULL area, take into account size and position of widgets  
with wind_calc(), and compute the real work area by removing height of the  
toolbar).

Now, it seems that wind_calc() is an heavy function in XaAES... For sure,  
we can take this into account in windom, and try to use others AES  
functions to do the same job if it works fine in other AESes too (windom  
is not designed for XaAES only)... and that's because  
wind_get(WF_WORKXYWH) is buggy in some AESes that windom uses wind_calc()  
to compute the WORK area, so we cannot safely use wind_get(WF_WORKXYWH).


Now, some words about the evolution of XaAES. I think that themes are  
great. Changing themes on fly is cool... i'm not sure it's very usefull  
(this may add complexity in all applications), but i've nothing against  
this ;)

My point of view about themes is it's global to the AES (all the  
applications should have the same look'n feel).

Now if you want to make this configurable on the fly, then the  
applications should do something (at least inform the AES that the  
application can handle change of theme). Then, AES should update all the  
windows created by this application (and maybe inform the application  
about it). One important thing : when the theme changed, the size of the  
work area shall stay unchanged. The FULL area may be changed by the AES in  
order to keep the WORK area unchanged if the widgets area bigger for  
example.

Last point : saying that values returned by wind_calc() are only relevant  
"in the moment if the window is not already opened" is not acceptable.  
this function shall always returns relevant data for all the windows  
(already opened or not) of the client.  This is mandatory to compute the  
FULL area of window before changing it. If the application accepts  
on-the-fly change of theme, then data are out of date when theme changed,  
but it's ok.

In other words, i don't think that theme-per-window idea is a good idea...  
That will render a dirty look'n feel, and that makes wind_calc() unusable.


best regards,
Arnaud.