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

[MiNT] usage of wind_calc()



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.