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

Re: [MiNT] usage of wind_calc()

Hello,


 I have implemented a new 'operating mode' in XaAES, called "Window
Coordinate Orientation WORK". There is some documentation about it in
newcalls.txt.
I like very much the way XaAES moves... You ask for comments, and then you implement your original idea without taking into account comments. It's good :( 


Please read and give me ideas.


read... and i still have the same idea about this evolution :(


I'm still convinced that
usage of wind_calc() should be restricted to its original purpose, i.e,
creation of new windows,


This is not the aim of wind_calc() ! where do you see that ???
The ONLY aim of wind_calc() is to convert WORK area from/to FULL area for a given AES application (the only contextual stuff is the aes_global array). 


or even completely depreciated.


So you want to deprecate wind_calc().


This work is
experimental, and far from perfect, but I seriously think this is the
route to take,


i do not...


make the FULL extent of a window completely indipendant
of the WORK area. That is, applications should only consider its WORK
area, and in cases it must know FULL extent for some reason (reasons
exists, no doubt) it is 'special case' and for that new wind_calc()
prelacing functions exists.
Why do you want application to use new calls when the AES calls that already exist can do the job ! Ok, standard AES function can't do the job if you deprecate wind_calc(), but i still don't see why you want to deprecate wind_calc(), and i still don't understand why you added this new work feature (i still don't see what these function may be usefull for). 


 The heavyness of wind_calc() can easily be omitted by caching results,


Good.

So, we don't need anything more.


but this is not preferred.
Why ? If some part of the AES needs cache to be performant, then let's implement some cache in the AES ! It's evident IMO. 


 I think I need a new explanation of why wind_calc() is necessary to
service WM_REDRAWs again. There is a bug in wind_get(WF_WORKXYWH).


Yes, an so, the only way to get the WORK area is to :
- get the FULL area
- convert FULL to WORK area (well, work area without TOOLBAR)
- remove "by hand" the height of the TOOLBAR to get the real WORK area of the window.
If we know that wind_get(WF_WORKXYWH) is reliable, then for sure we can use it. A bit in appl_getinfo (the bit that indicates wind_set(WF_WORKXYWH) is available) may be used for that purpose too. 


Furthermore, WM_REDRAWs, at least in XaAES,
never deliver coordinates outside a window's WORK area.


so wind_get(WF_WORKXYWH) is bug-free in XaAES :)


The goal is to find usefull alernative to wind_calc(), it's not to
deprecate wind_calc().


I don't understand.
If you want to find alternative to wind_calc(), it's because you don't want applications to use wind_calc(). In other words, you want to deprecate wind_calc(), no ? 


 wind_calc() will always be present, but its usage should be depreciated
when alternatives exists.


So you create alternative in order 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.


 And a third one;
 - applications like virtual desktop managers, global window cascading
applications, etc. These need access to every window's geometrics, not
just the ones created by itself.
Ok, let's talk about these kind of application. They may want to control over foreign windows (windows owned by an other application). Such application does not need to know anything about the "work" area of foreign windows. The only information that may interest such application is the FULL area of foreign windows. wind_calc() is never usefull here.
So, this 3rd kind of application is out of the scope of the wind_calc() discussion. We cannot argue about wind_calc() by using this 3rd kind of application.
Furthermore, the only way an application have to control foreign windows is to send AES messages (WM_MOVED...). But your work option stuff, how the 3rd kind application can know if the foreign application has or not set this WORK option for this window ? 



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.


 I dont see a reason, other than it becoming "complicated" for lib
developers to keep all hacks and support XaAES at the same time, to put
such a restriction on ourselves.
And then there's the third kind of
applications....


I don't see any restriction.

As see before, the 3rd kind of application is a bad argument.
The only i see is "wind_calc() must be deprecated", but it's not an argument for me because i still don't understand why you want to deprecate wind_calc().
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.


 I do. I will keep wind_xget(WF_CALCW2F/WF_CALCF2W) as replacement for
wind_calc(), because these will always deliver correct results, no
matter what :)
But with wind_get(WF_WORKXYWH) and wind_set(WF_WORKXYWH), the convertion between WORK and FULL area are no more usefull... except before creating a window, and there wind_xget() could not be used. 


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.


 Reliable long as the values returned are not applied to an existing
window. For your two application type above, you 'maybe' right (maybe,


not 'maybe' : it's sure.
If it's not sure, then wind_calc() shall never be used and whall be removed from the AES right now ! 


because we dont know what the future brings, if anything). But for the
3rd kind of applications this is very false.


not agree. 3rd kind of application is a bad argument.


I want to remove this
problem, and try to do it so that such problems are gone forever.
I don't see any problem ! I still don't understand what all your new features are for ? To add complexity for developpers, yes i see that :/ it's the only purpose i've found up to now... 



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.


 This is what I want to change.


Why ?
Because wind_calc() should be deprecated if i get you... but why do you want to deprecate wind_calc() ? 


With WCOWORK mode, wind_open() accepts
WORK coordinates (and thus no need to use wind_calc()).
I see... now, instead of using wind_calc() from time to time, applications will have to use wind_xget() with new modes to do the same job ! an this is window dependant ! The kind of computation and functions to call depends on the window handle ! 

I really don't like at all this evolution.
Furethemore, i think this is incompatible with windom (i don't want to support an XaAES only branch of windom... which will be much more complex that the "common to all AES" branch)... So we'll have to add a "please never use the XaAES WORK feature" in windom documentation... I think it's ok for everyone because the WORK feature doesn't help the developper. 


 Yes, evolution sucks, eh?


No, only bad evolutions ;)

i want evolutions, but good one : evolution that are usefull.


I think this is necessary to 'move on'.
Yes but move to somewhere; not move around to do the same stuff with other incompatible functions. 


I
will go forward with this, and see what happens.


If it's the way you want to discuss... it's fine :(


I refuse to let old
bugs in no-longer-supported AES's stop XaAES.
The only bug that forced windom to use wind_calc() so often is wind_get(WF_WORKXYWH), and this is now fixed, so there is no more pending bug related to our discussion. 


If this is not
appreciated, now is the time to make a separate 'n.aes==xaaes' source
tree.


I don't get you there.


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.


 So, operating in WCOWORK mode you can still do that, because WM_MOVED
then contains WORK area coordinates, and wind_set(WF_CURRXYWH) is the
same as wind_set(WORKXYWH). This means that for the rare occasions where
Ok, i won't tell you to read the whole window source code. This is just an example, and the problem is still there. When windom will call wind_set(WF_CURRXYWH), then maybe the parameters will be taken as FULL area, or as WORK area... windom don't know because windom don't know if the application has done a WF_OPT or not before for this window. 


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 ?


 For applications that try to work on all AES's this adds complexity,


Even if you want to make a windom for xaaes only this will add complexity.


agreed. But I do not think the complexety is great.
Try experimenting
with it, and see how easy it actually is.
Overall, i still dont understand the aim of this complexity : what's the marvelous feature hidden by all these new functions ? I still only view complexity and incompatibility issues only. No gain at all.
Last note: all this is because of the "on-the-fly" theme change if i get you right... a feature that should not add any complexity to application IIRC :/ 


best regards,
Arnaud.
PS : If all goes right, i'll be offline ( short holidays, but holidays :)).... right now. I'll be back online 4th july. Don't expect an answer until then.