Re: [MiNT] usage of wind_calc()

[Odd Skancke <ozk@atari.org>]

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

 Why? This is a defined behaviour and will never change! But look
further down...

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

 Ok, for old apps we need to keep wind_calc() and its usage as is.
However, wind_calc() should never be used in new apps where the
developer knows about XaAES.

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

 This is not a supposition, it is a defined fact that will never ever
change unless explicitly supported by the application, in which case
wind_calc() is never used.

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

 And here lies the problem altogether, using two different window areas,
which I want to discuss .. look further down.

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

 Yes, this is correct. If applications only had to deal with ONE area of
the window, all problems would just magically vanish! :) I have
implemented wind_set(WF_WORKXYWH), and right now I'm doing some tests
using Qed sources. wind_calc() should be unnecessary under XaAES to
ensure correct behaviour in the future :)

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

 This will only work for applications that tell the XaAES it supports
geometric changes of existing windows. With the suggestions I have
further down, this would work always ;-)

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

 Assuming we make sure we create a situation for ourselves that per-
window theme changes is impossible, wind_calc() would work in this case
because wind_calc() would base the calc on the input. I dont want to
block out any posibility because it is 'a bit simpler'. So, please
consider my ideas of getting rid of wind_calc() usage altogether.

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

 Yes, for a not yet existing window it is. The only reason wind_calc()
does not take a window handle, or have a equivalent function for work on
explicit windows is that themes was not a thema back then.

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

 Actually, you are right. I dont think there is a use for these by
applications that know about wind_set(WF_WORKXYWH). If app dont know
about the new wind_set possibility, it wont know about the above calls
either :)

> 
> Please let's start at the beginning and consider our 3 requirements (if  
> you see some others, please add 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. If we remove the need to convert WORK coordinate to FULL and
vice versa, wind_calc() would not be necessary. This would enable the
AES to change any aspect of the window without even notifying the
application, as long as WORK area stays the same. In cases where WORK
area do change because of theme changes or things related to that, a
WM_MOVED or WM_REPOSED will notify it. Just to illustrate; this would
allow us to use different sized title-bars based on fonttype/size on
topped/untopped windows. The AES is given total freedom/control if the
application only relates to its WORK area and nothing else! This
involves having all the window related AES functions pass/take WORK
coordinates. I will attempt to comment your requests...

> 
> REQ1 : the AES shall provide to the application a way to open a window  
> with a given WORK area position/size

All coordinates are WORK areas.
 Application calls wind_create(kind, x, y, w, h)
 Application then calls wind_open(handle, x, y, w, h)
 WM_REDRAW are generated and sent
done.

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

 wind_set(WF_WORKXYWH) corrected
 done.

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

 wind_get(WF_WORKXYWH) corrected
done.

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

 This is correct, and will be kept like this for ever :) If the
application supports XaAES, this sequence of events are reduced to two
AES calls.

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

 Given the situation where wind_get(WF_WORKXYWH) cannot be used, this is
the only way, yes. This is the 'old' way of handling this request. If
application knows about XaAES, this request is done in one AES call.

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

 Again this is because of bugs in the original AES's. With XaAES the
bugs are gone in wind_get(WF_WORKXYWH) and can be used. All the above
computations are not necessary and AES calls needed reduced to one.

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

Yes, for old apps this is true. For new (that is, apps we can modify, or
is still supported) wind_calc() is no longer necessary.

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

 correct

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

 correct.

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

 Yes.

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

 True. But this must change for new applications.

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

 This brings me to the only problem I have regarding my suggestion to
make applications use only WORK area of windows. What happens if the
window has no work area? That is, the window has a toolbar and sized so
that only the toolbar is visible, so that WORK area's width/height
become 0 or negative. What should WM_SIZED, WM_MOVED WM_REPOSED messages
contain in such situations? Should it be possible for a window to have 0
or negative w/h, or should the AES stop sending WM_SIZED (but still
allow for resizing smaller than WORK area)? WM_MOVED messages could
contain x, y, 0, 0, which could be passed directly to wind_set
(WF_WORKXYWH) which would then set new x/y.

 This also means the smallest window size will be that of the windows
minimum WORK area. 

 Please give me your comments/ideas suggestions here!

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

 Yes, I agree. Especially now that I've started thinking apps should
only relate to a window's WORK area :-)

> 
> Please, lets try to be as simple as possible.

 Absolutely.

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

 Agreed.

> 
> BTW, mt_gem.h.in is the file to update. Then the makefile will generate  
> mt_gem.h

 Thanks. I will ask here on this list (if noone thinks its offtopic)
before I do any modifications to the CVS tree :-) Dont wanna make myself
look as stupid as the last time I messed up.


 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.

 Alls wind_get/set() functions that work with coordinates expect WORK
area coordinates. Yes, even wind_set(WF_CURRXYWH)

 wind_calc() will always return the same it was given.

 And all the other things I dont think of right now.

 This gives the AES full freedom to do whatever it wants to any window's
borders without notifying the application as long as WORK stays
unchanged.


 Comments, suggestions .. ideas?



 Best Regards,
Odd Skancke