Re: [MiNT] usage of wind_calc()

[Odd Skancke <ozk@atari.org>]

fre, 24,.06.2005 kl. 01.34 +0200, skrev Henk Robbers:
> 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?

 This approach is what most applications use, I think. And this will
work great, because as I said before, existing windows will never change
geometrics unless application tells the AES it supports it. Then the AES
will send notification to the app that it needs to obtain new geometrics
data. This is also the reason I think its a good idea to let theme
changes only affect 'windows created hereafter' if application dont know
theme changes.


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

 Exactly :)

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

 Ah, good ;-)

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

 Yes, definately. As in another post, this is what I'll make it behave
like I think.

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

 Hmm... I dont know if applications should know about themes like that.
I think it suffices to add the suggestions I made in my reply to Arnaud.
I think that if multiple themes is to be used, this should be user 100%
user controlled and kept transparent to applications. So that, for
example, the user can have HighWire use its own theme, while text
editors use another while alert windows have yet another theme in a
type-by-theme'ish scheme. However, letting applications gain control of
themes is not a good idea, I think.

> 
> 
> To Odd:
> Hi Odd
> 
> A version of wind_open that takes a work area rectangle as input
> might be an idee?
> 

 Yes, in addition to the other work area rectangle suggestions I made in
my original reply to this post of Arnaud's :)


 Best Regards
Odd Skancke