[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] usage of wind_calc()

Hello,
We agree on a lot of things, but for some points it seems that we don't understand each other... and this discussion tend to become a big soup with all and nothing inside. I think it's time to make a point. 

I'll try to sum up once again :)
ok, the main sensitive point is that wind_calc() may be a heavy function in some AESes, and so we have to find how we can use others AES functions to do the same thing for critical pieces of code, i mean piece of code executed for WM_REDRAW messages for example. The piece of code that create a window may use wind_calc(), it's not critical.
The goal is to find usefull alernative to wind_calc(), it's not to deprecate wind_calc(). 

The other point is about themes. I see two kind of applications :
- applications that cannot handle on-the-fly change of theme (typically, old applications) : here, if the user changes on-the-fly the theme of the AES, then the AES will keep using the old theme for that application, even for window opened after the change. This is needed because such application may have memorised border size of window (computed from wind_calc).
- applications that can handle on-the-fly change of theme. Here, if the user changes on-the-fly the theme of the AES, then the AES will change the theme for all already opened windows, and for window that will be open later too of course. 

Do we agree on this ?
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 for window that will be open in the futur... Of course, such value must not be memorised because it may become out dated if the theme changes. But if the theme change, for application that support change of theme, the theme of all windows are updated with the new theme, and so wind_calc() still returns reliable informations for all 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.
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. 

Please tell me if we agree on that.
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



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)
REQ3 : the AES shall provide to the application a way to get the WORK area 
position/size of a window.
We saw that if AES provides wind_get(WF_WORKXYWH) and wind_set(WF_WORKXYWH), then REQ2 and REQ3 may be fulfil without using wind_calc().
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. 


So no further modifications are needed.
If you want to change something else, it's because you have some other requirements for applications, and please list them. 


 Ok, now I will explain the idea I have now, which came from a comment
you made above; Applications only know about the WORK area of windows
they use.
No. Please remove the "only" word and i agree. The point is that applications NEED to know about the WORK area, but applications also NEED to know about the FULL area.
For example, when a window is full-sized, application may set the window to the whole screen, and for this, the only way is to work with FULL area. Another example: an application is a drawing application, and it has a vertical tool window on le left of the screen - when the image window is opened, the application open it to cover the whole screen except the tool window, and to do that, it have to work with FULL area of windows. Another example: an application provide a way to re-organize the windows (mosaique, cascade...) : all this is a work on FULL area.
Application should be able to work on both FULL and WORK area... but hey! wind_get/set(WF_WORKXYWH) and wid_get/set(WF_FULLXYWH) both exist ! AES already provides all we need. 


If we remove the need to convert WORK coordinate to FULL and
vice versa, wind_calc() would not be necessary.


True because this is the aim of wind_calc() ;)
But if you follow me, the goal is not to deprecate wind_calc() even for new applications. I don't see any reason to do that...
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 : 


 Implementation suggestions;

 For new applications that detect WORK area oriented windowing by
checking appl_getinfo() the following is done;

 wind_set(-1, WF_OPTS, 1, WO0_WCOWORK, 0, 0)
 (WindowCoordinateOrientationWORK)

This will turn the AES into "application only gets WORK coordinates"
mode, and affects the following things;

 WM_MOVED, WM_SIZED, WM_REPOSED, WM_ICONIFY, WM_UNICONIFY, WM_ALLICONIFY
contain WORK area coordinates instead of FULL coordinates.
I don't like this proposal because that will create another way to treat these messages.
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.
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.
In fact, the very main reason against the proposal is that it add complexity in developpement... and what's for ? What's the requirment ? Why the need for this option ?
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).
Ok, there's some points that we didn't discussed yet about wind_set(WF_WORKXYWH)... will discuss them later when we agree on the main solution (only wind_get/set are needed). 

best regards,
Arnaud.