Re: [MiNT] usage of wind_calc()

[Odd Skancke <ozk@atari.org>]

lør, 25,.06.2005 kl. 17.31 +0200, skrev Arnaud BERCEGEAY:
> 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.

 This is a much better method than using wind_calc(). A windows's
work/full area relationship is guaranteed never to change! wind_calc()
is context-less, and its output is not guaranteed to be applicable to
existing windows. The only chance of a geometric change of an existing
window is if the application tells the AES it supports it, in which case
the AES lets the application know if so happens. So, imo, Henks method
is the correct one.

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

 Yes, you mean windows that are scaled as it gets smaller ;-) This
sounds nice, but again, this wont be working no matter what on older
apps, and certainly not by using wind_calc(). Problems once two windows
have different sizes...

> 
> The widget stuff is an AES stuff, and if the application wants to compute  
> WORK<->FULL conversion, then wind_calc() is here.

wind_calc() should never ever be used to calculate such stuff for an
existing window. But I understand it has been used due to the problems
you explained earlier. But this has got to change! :)

 I have implemented 4 new wind_get() modes which will cover all things
that is needed.

wind_get(handle, WF_CALCF2W, x, y, w, h)
wind_get(handle, WF_CALCW2F, x, y, w, h)
wind_get(handle, WF_CALCF2U, x, y, w, h)
wind_get(handle, WF_CALCU2F, x, y, w, h)

 WF_CALCF2W will convert the FULL area coordinates passed to WORK area
coordinates (same as wind_calc(WC_WORK))
 WF_CALCW2F will convert the WORK area coordinates passed to FULL area
coordinates (same as wind_calc(WC_BORDER))

 The other two modes deal with a new area definition, which I want some
comments on. This is called the USER area, and by definition this is the
area of a window which is used by the USER. As of now, only the TOOLBAR
widget of the defined widgets is a part of the USER area of a window,
and if no toolbar is in use, the USER area is the same as the WORK.
Anyone got comments on this?

 I think we need a wind_xcalc(handle, request, kind, x, y, w, h) call to
be able to calculate using different widgetmasks than what is currently
in use by the given window. request's could be as follows;

 WC_BORDER  <- input coordinates are WORK area, output is FULL area
 WC_WORK    <- input coordinates are FULL area, output is WORK area
 WC_FULLUSR <- Input coordiates are FULL, output is USER area
 wC_USRFULL <- Input coordintes are USER, output is FULL area

 I will implement this and make tests ... comments please?

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

 Yep, agreed as long as the situation is that wind_calc() is used like
this.

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

 These functions I have implemented too, but not had them tested yet. I
need to conduct tests using QED and gemlib, but all of the sudden I dont
remember how to correctly add WF_CALCx2x mode definitions to gemlibs's
headerfiles ... 

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

 Yes I agree 100% here, no application should think about themes,
certainly not be able to change them.

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

 Well.. it can get messy quickly, but if such things is completely (and
ONLY) userconfigurable, it could be nice. But this is for the future,
and if we find and agree on a way around the wind_calc() problem, this
is gonna be easy to implement later....

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

 Agreed. I'd also like to add that apps should not know that much about
themes.


 Best Regards
Odd Skancke