Re: [MiNT] usage of wind_calc()

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Sun, 2005-06-26 at 21:57 +0200, Arnaud BERCEGEAY wrote:

> The other point is about themes. I see two kind of applications :

> Do we agree on this ?

I agree - app either can change its themes, or it doesn't.  No app
should use more than 1 theme at once.

> If so, then for a given application, all the windows of that application  
> use the same theme. So, when an application invoke wind_calc(), then the  
> value returned is reliable for all the windows already opened, and well as  

I also agree that wind_calc() is still useful in defining the
relationship of a full window to a working window.

> To sum up, i see no reason why wind_calc() should be deprecated... or why  
> the use of wind_calc() should be forbidden because of themes.

Agreed.

> The only think i see about about wind_calc() is that it's a heavy  
> function, and so we may try to replace wind_calc() by something else in  
> speed-critical subroutines. In all cases, the values returned by  
> wind_calc() are still reliable.

The work done with caching the results should make that a non-issue now.

> I make the hypothesis that we agree, and i'll try to find why wind_cal()  
> is used at the moment. This is the list of requirements hereafter :
> 
> >> REQ1 : the AES shall provide to the application a way to open a window
> >> with a given WORK area position/size

May I suggest that if given a working area that would cause any of the
windows widgets to be outside the screen, then it should simple return a
full-screen window and the application will get a window with a smaller
working area than requested.  This means these coordinates may have to
queried after the call.

> >> REQ2 : the AES shall provide to the application a way to change the WORK
> >> area position/size of a window (AES will change the FULL size of the
> >> window in consequence)

See comment above!

If you plan on adding wind_set( WF_WORKXYWH ), then yes, REQ1: can be
filled by wind_calc().   However, I'm not sure when you would change the
window size based on its working area - normally window size changes are
done via user interaction.


> >> REQ3 : the AES shall provide to the application a way to get the WORK  
> >> area
> >> position/size of a window.

wind_get( WF_WORKXYWH )

> For REQ1, as wind_calc() always works (even if it's a slow function, it  
> works), then applications can keep using wind_calc() to compute FULL area  
>  from wanted WORK area.

Agreed.

> About you suggestion to work on WORK area for all the wind_xxx stuff, i  
> really don't think it's a good idea. Comments hereafter :

> I don't like this proposal because that will create another way to treat  
> these messages.

I'm also kinda questioning the benefits.  

If you really want to simplify the interface, then take things a step
further, and give the application coordinates relative to the window
(and have the VDI also take window relative coordinates).  No clipping
rectangles should extend beyond the window.  Application shouldn't know
or care about window moves, or iconify operations - let the AES handle
it all.  All it needs to know is the width and height of the area it has
to work in.  Now, that model would be sufficiently simplified and
possibly faster in some ways.

> For example, at the moment, when an application receives a WM_MOVED  
> message, then the application calls wind_set(WF_CURRXYWH) with buff[4..7]  
> as parameter. This is automatised in windom : most of windom applications  
> don't care about such messagesn all is managed by windom... but the  
> application can take control of such event if needed.

I kinda agree to keep it in userspace.  The above would mean moving it
from the control of the application to reduce redundant code and remove
extra task switches.

> What i try to say is if a windom applications choose this option, then the  
> developper will have to write its own event handler for all the messages,  
> because windom won't be aware of this option.

Yes, Windom wouldn't perform that call.  I think the suggestion was for
new code only.

> All i see is that wind_get/set(WF_WORKXYWH) solve all our problems, and  
> wind_calc() remains here for the only case it is needed (convert WORK to  
> FULL area for wind_open).

Agreed.