Re: [MiNT] usage of wind_calc()

[Henk Robbers <h.robbers@chello.nl>]

Arnaud BERCEGEAY wrote:
> Hi list,
>
>
> 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).

In all my GEM programs I keep track of many rectangles
about a window. One of them is the "border size" rectangle.
Its components x,y,w,h contain the distances from the work area
to the full area in all four directions.
I use wind_calc to obtain these values.

I use it after I know where I want the workarea and before I
create and open the window. So I need and use wind_calc only
once per window.

I have always understood that this is the essential function
of wind_calc.

Whenever I need to recalc either full or work area, I use my
own "border size" rectangle. I need only 4 adds or subtracts.
Not even a AES call.

Might be a good idee for WINDOM?

You are right that wind_calc can not be deprecated, but its usage
can easily be kept very low.

wind_calc is essential because it gives you the amount of space
occupied by window borders independent of AES and screen resolution.
Part of this essence is that its usage is associated with windows
in general, not a particular window.



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

I would like to use different themes for different type of content
within the same application.

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

That is a very good point.

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

True, but you only need to call wind_calc after such a change.
In stead of keeping poised on "already existing" windows I would
suggest that wind_calc would get a version where you can specify
both a widget mask and a theme identification.
It can then be held independent of a given really existing window
and would hold on to its original design constraints.


To Odd:
Hi Odd

A version of wind_open that takes a work area rectangle as input
might be an idee?

--
Groeten; Regards.
Henk Robbers.    mailto:h.robbers@chello.nl
                   http://members.ams.chello.nl/h.robbers/Home.html
Interactive disassembler:     TT-Digger;  http://digger.atari.org
A Home Cooked teXt editor:    AHCX