Hello,
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?
I don't like the idea because i don't want windom (and any application) to make false assumptions about the size of widget. With such computation, you assume that size of left/right/top/bottom borders of the window will kept unchanged. At the moment, i think it's true for most (all) AESes... but that may change.
I can imagine an AES that change the size of the borders (smaller borders, smallers widgets, smaller font...) when the size of the window becomes small, in order to have a relative high WORK area in the window when the window is small.
The widget stuff is an AES stuff, and if the application wants to compute WORK<->FULL conversion, then wind_calc() is here.
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.
If application doesn't know theme change, then wind_calc() shall still return reliable data for already opened window, and that's why the only way to keep these applications working is to have a application basis for theme change (see my other post).
You are right that wind_calc can not be deprecated, but its usage can easily be kept very low.
Sure, all we need is a relevant wind_get(WF_WORKXYWH) and wind_set(WF_WORKXYWH)... and something in appl_getinfo() to inform the application that these functions exist and return reliable data.
> 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 ;-)
Ah... not good :/IMHO, theme stuff are AES stuff. The user shall choose the theme the AES will use. The application doesn't have his word to say. The application should not be able to change the theme.
Now, we can imagine an intelligent AES that can apply a theme for text editor applications, another theme for terminal, etc... but it's a bad idea IMO.
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.
The problem is only for applications that don't support theme change, and so it's useless to add new AES functions for these applications. The best we can do is to try to keep them working, and the "theme per application" way is a solution (the other solution is terminate applications that don't support theme change). The "theme per window" basis will break the compatibility.
best regards, Arnaud.