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

Re: [MiNT] wind_xget()


> Ok, in that case .. is it OK if we use;
>wind_get(handle, WF_FIRSTAREAXYWH, area_x, area_y, area_w, area_h);
>and leave the original WF_FIRSTXYWH unchanged? I will implement it right
>now.... if there are objections, please speak up.
For me no problem, I have add this feature for Arnaud in the past, so
what think Arnaud? For me no problem.

 Lets await his comments then...

the call should be wind_xget_grect( handle, WF_FIRSTAREAXYWH, grect_in, grect_out);

i mean... just like it was before, we just change the opcode from WF_FIRSTXYWH to WF_FIRSTAREAXYWH, right ?

It's ok for me.

The missing piece is a way to detect the availability of this function. I propose appl_getinfo(AES_WINDOW(=11)). bit 9-15 of out1 seems to be unused at the moment, so bit 9 may be used to indicate that WF_FIRSTAREAXYWH is implemented.

About the detection of XaAES by using wind_get(WF_XAAES):
> I have kept this
>only because Arnaud asked me to keep it. Are there any apps that check
>XaAES presence this way?

 Arnaud, do you think it will be a problem removing this, and come up
with a way to obtain such info via appl_getinfo() instead?

ATM, windom uses that call to detect the presence of xaaes (function vq_xaaes() of windom). Windom internally use this function to detect the availability of MENU in window. If vq_xaaes()>=0x963 then windom may use AES wind_set(WF_MENU) to install menu in window.. and let the AES handle the menu. If xaaes is not detected, then windom uses its own menu management to install a menu in the window and handle it.

I think it's a good idea to have a new appl_getinfo() mode to return informations about the AES, but i don't see why wind_get(WF_XAAES) should be removed. ok, wind_get(WF_XAAES) is not the best choice for aes detection... but it's not worst than wind_get(WF_WINX), and it's better than cookies ;)

BTW, i don't care if wind_get(WF_XAAES) no more work. it's ok for me.

About identification of AES, if i sum-up, we have:

#define APGI_VERSION 96
appl_getinfo(APGI_VERSION, &min_version, &maj_version, &arch, &status)

and for APGI_AESINFO (value = 0x5800 ???), we can think of an alternate version of appl_getinfo()... something like:

appl_getinfo_str( short mode, char *str1, char *str2, char *str3, char *str4);
which set
aes_addrin[0] = str1;
aes_addrin[1] = str2;
aes_addrin[2] = str3;
aes_addrin[3] = str4;
and aes_control[2]=1 (intead of 5) to tell that nothing is expected in intout[1..4].

So the AES shall check the number of entries for addrin and intout in aes_control[] to check which appl_getinfo is called. We even can go further and use the same mode (APGI_VERSION) for both:

short min_version, maj_version, arch, status;
char aes_name[64], aes_version[64];

appl_getinfo(APGI_VERSION, &min_version, &maj_version, &arch, &status)
appl_getinfo_str( APGI_VERSION, aes_name, aes_version, NULL, NULL);

aes_name will be filled in with "OurAES"
aes_version will be filled in with "1.02b (25 dec 2004)"

opinions ?

best regards,