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

Re: [MiNT] usage of wind_calc()

Hello,
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!


I disagree here.

The prototype of wind_calc is the following :
short mt_wind_calc ( short Type, short Parts, short InX, short InY, short InW, short InH, short *OutX, short * OutY, short * OutW, short * OutH, short * global_aes);
We can use this function to get the FULL area of the window (OutX/Y/W/H paramters) that correspond to a given WORK area (InX/Y/W/H parameters). The assumption that the delta between InX and OutX is constant is just a supposition you've done. At the moment, this supposition is true for all windframes (AFAIK), but i don't see why this may not change. 


wind_calc()
is context-less, and its output is not guaranteed to be applicable to
existing windows.


This is wrong.
Saying that is saying values returned by wind_calc() are not reliable... or that wind_calc() shall not be used. 



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.
This method is correct while the supposition "borders of windows are constant whatever the size of the window" is true.
I won't say it's a correct method because this make supposition on stuff (window widget) that application may not take care of.
The need for an application is to get/set the FULL/WORK area of a window. wind_calc is here because of the lack of wind_set(WF_WORKXYWH) and because wind_open() expects FULL area only.
If there's a way to do such things, then wind_calc() is no more usefull... or in other words, applications may use other AES functions to do the same thing.
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,
This won't work for application that has done the supposition about constant width/height/position of widgets. I don't know if a lot of old applications are concerned. 


and certainly not by using wind_calc().
Problems once two windows
have different sizes...


wind_calc() works fine in that case. I don't understand you.
When you invoke wind_calc(), the dimension of the window are specified in input. The function compute the output are for the given input area.
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.


Why ? This is the only AES function to do such conversion !


But I understand it has been used due to the problems
you explained earlier. But this has got to change! :)
The only change will be a "note" added in the wind_calc() documentation, to explain that wind_calc() is an heavy function in XaAES and that other AES functions should be used instead. 


 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)


I don't understand the need for such functions...
Please let's start at the beginning and consider our 3 requirements (if you see some others, please add them) :
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. 


What's the situation now (with current AESes) ?

For REQ1 :
- application has a wanted WORK area position/size.
- application calls wind_calc() to get the corresponding FULL area position/size - application opens the window by calling wind_open() and the FULL area position/size returned by wind_calc(). 

For REQ2 :
- application has the new wanted WORK area position/size.
- application calls wind_calc() to get the corresponding FULL area position/size - application changes the window FULL area position/size by calling wind_set(WF_FULLXYWH). 

For REQ3 :
- application gets the FULL area position/size by calling wind_get(WF_FULLXYWH) - application compute the "false" WORK area position/size by calling wind_calc() - application compute the "real" WORK area position/size by taking into account the toolbar if needed.
How to get ride of wind_calc() in these situations... I'll make suggestions. Comments are welcome.
For REQ1, no change... wind_calc() is still needed. This is not a problem because this only happend once when the window is created (for REQ2 and REQ3, this may happen in each WM_REDRAW message). 

For REQ2:
- application changes the WORK area position/size by calling wind_set(WF_WORKXYWH) 

For REQ3:
- application gets the WORK area position/size by calling wind_get(WF_WORKXYWH) 


What's the consequence for the AES...

=> wind_set(WF_WORKXYWH) has to be implemented.
=> wind_get(WF_WORKXYWH) must work properly (remove the size of the toolbar) => a bit set to 1 in appl_getinfo() to tell the world that wind_set/get(WF_WORKXYWH) work fine.
About the new functions, i don't see who can need them... IMO, the widget stuff should be private to the AES : application don't have to evaluate "what will be the WORK area if i set the FULL area to this or that".
At the moment, applications do this by calling wind_calc() because there's no other way to answer REQ1/2/3 above. 


 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?
Yeah : if the toolbar is managed by the AES (toolbar installed by calling wind_set(WF_TOOLBAR)), then the toolbar is in the scope of the AES. Application doesn't have to know where this toolbar is located precisely... and moreover, application cannot do anything with this information. It's useless... 


 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;
I don't think so. If you agree on my proposal for the 3 requiements, then wind_set/get(WF_WORKXYWH) are enought for everybody. 

Please, lets try to be as simple as possible.


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 ...
WF_CALCx2x are not needed, and are useless IMO. Please forget that solution.
BTW, mt_gem.h.in is the file to update. Then the makefile will generate mt_gem.h 


best regards,
Arnaud.