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

Re: [MiNT] wind_xget()



 Hi

tir, 14,.12.2004 kl. 09.10 +0100, skrev Olivier Landemarre:
> Odd Skancke wrote:
> 
> > Hi Olivier,
> > If you hope to fix this compatibility issue, I would strongly suggest
> >that we agree on a new wind_get mode instead. I will for sure not follow
> >the current implementation.
> >  
> >
> I will look at this.
> 
> > I think that mode 13 is free for use, between WF_NEXTXYWH(12) and
> >WF_NEWDESK(14). Anyone know if this mode is used for anything?
> >
> >  
> >
> For me I never see program using it.
> 

 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.

> In MyAeS I have add an appl_getinfo() extension for know wich AES and 
> version is avaible (I think better than search in
> a cookie list!)
> #define AES_NAME_AND_VERSION 96
> 
> case 96: /* AES_NAME_AND_VERSION */
>             pb->intout[1]='My'; /* 3 first value are a short name for 
> the AES*/
>             pb->intout[2]='Ae';
>             pb->intout[3]='S\0';
>             pb->intout[4]=0x0067;    /* last value is version with lower 
> byte, the major version number and lower byte the minor number version 
> all in hexadecimal */
> 
> I dislike add new fonction feature because most of time never use, this 
> only  because a lot of people ask me to know wich AES is use, and I 
> didn't wan't add cookie.

 Not sure what you mean here. I also dislike adding functions for this,
and I strongly dislike the wind_set(WF_XAAES) thing. I have kept this
only because Arnaud asked me to keep it. Are there any apps that check
XaAES presence this way?

 However, I will add appl_getinfo(AES_NAME_AND_VERSION) to be consistent
with MyAES. But I would also like to make more versioning info available
via appl_getinfo(). I have halfway implemented appl_getinfo(0x58xx)
where xx is a mode between 0 and 255. (0x58 == 'X'), and mode 0 returns
the following;

 ap_gout1 = Minor version number
 ap_gout2 = Major version number
 ap_gout3 = Arch (for example, 0 means m68k, 1 means ppc, etc)
 ap_gout4 = Status (for example, 0 means stable, 1 means beta, 2 means
alpha etc.)

 We should agree on the version number, tho. In addition to this, I
would like to add more verbose info available via appl_getinfo() when
the above appl_getinfo() exists. For example, and idea, if we use 96 to
return versioning info like I suggest (96 is only available in MyAES and
XaAES as of yet, and we can change it because not too many apps use it
yet?) we can call this mode APGI_VERSION.

#define APGI_VERSION 96

 Then we can say that "If APGI_VERSION is available, APGI_AESINFO is
also available" (whose function number we agree on).

 appl_getinfo(APGI_AESINFO, &aes_sname, &aes_lname, &aes_arch,
&aes_status);

 where pointers to char-buffers which the AES fills in is passed in
addrin[0-3].

 This will then tell the application that extended appl_getinfo
(APGI_AESINFO) is available by calling appl_getinfo(APGE_VERSION), like;

have_aesinfo = appl_getinfo(APGI_VERSION);
if (have_aesinfo)
{
   min_ver = intout[1];
   maj_ver = intout[2];
   arch    = intout[3];
   status  = intout[4];
   /* since APGI_VERSION exists, APGI_AESINFO also exists */     
appl_getinfoAPGI_AESINFO, &short_name, &long_name,
                          &arch_string, &status_string);
}

 Opinions on this?

Regards,
 Odd Skancke