Re: [MiNT] usage of wind_calc()

[Odd Skancke <ozk@atari.org>]

 Hi Arnaud,

tor, 23,.06.2005 kl. 23.32 +0200, skrev Arnaud BERCEGEAY:
> 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.

 Thank you so very much for a decent explanation of the problem ,-))

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

 Ah, this clears the situation up quite good :-) Under these
circumstances I understand the use of wind_calc(), since no other AES's
have what I want to implement :-) But this has got to change...

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

 If applications always use wind_get/set() to figure out border sizes,
etc., no complexity is added. However, since this is not the case I
think that theme changes should only affect new windows. If the
applications indicates that it supports theme changes, all that
applications existing windows will be affected by the theme change.

 About the usefulness .. I agree it is not very useful in a productive
way. But I'm sure this, as part of a truly configurable AES, will
attract users :)

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

 Agreed 100%. However, given the situation, one have to give a little to
gain a lot, and altho not optimal, having theme changes not affect
existing windows will make older applications work too. The idea is to
try not to break compatibility. I think that theme changes are done
seldom by users, but when it is used it is better the user can choose to
quit/restart apps that dont support 'on-the-fly' changes rather than
being forced because windows become ugly/unusable :)

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

 Agreed. Will opt for this behaviour.


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

 Well, that is the definition of 'context-less', imo. 

> this function shall always returns relevant data for all the windows  
> (already opened or not) of the client.

 This is impossible if the application do not support theme changes.

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

 I dont know how most apps use wind_calc() yet, but it may be that theme
changes can only affect new applications (so that wind_calc() work on
the theme used by the current app) instead of new windows. Time will
tell. Since wind_calc() in XaAES is heavy, I would have noticed if other
apps use wind_calc() like WinDom earlier. The speed, or lack of it, was
frigthening before I cached the wind_calc() results.

 Please dont let the fact that AES's (Yes, I dont think XaAES dont take
all work-area eating elements into account) have a buggy wind_get
(WF_WORKXYWH) stop us from evolving. We can at least two ways here,
either extend wind_calc() to take a window handle for which the
calucations should be done, or add a wind_get(WF_WCALC, ..) / wind_get
(WF_FCALC) modes. One takes full and return work, the other vice versa.
I will also make sure XaAES's version of wind_get(WF_WORKXYWH) return
correct work area as soon as possible. The important thing, which will
fix all problems regarding this, is that the calculations are done on a
specific window.

 suggestions;

 wind_get(WF_WCALC, handle, x, y, w ,h) - return the work are of window
when full extent is x,y,w,h.

 wind_get(WF_FCALC, handle, x, y, w, h) - return the full extent of
window when work area is x,y,w,h.

 wind_calc(handle, rquest, x, y, w, h) - if handle is NULL then a normal
wind_calc() - that is using the currently inuse theme (ONLY WHEN INFO
FOR A NEW WINDOW IS NEEDED). Else calculate using the given window-
context.

 Then we can add functionalities that make it possible for apps to
receive WM_SIZED/MOVED/REPOSED messages with work-area coordinates
instead of full-extent ones in addition to
wind_set(handle, WF_WORKXYWH, x, y, w, h)

 These are very easy things to do in XaAES, and will create lot less
overhead if libs like WinDom uses it.

 What do you think? If you have other ideas, please let me know.



 Best Regards,
Odd Skancke