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

Re: [MiNT] wind_xget()

Odd Skancke wrote:


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.
For me no problem, I have add this feature for Arnaud in the past, so what think Arnaud? For me no problem.
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.


It's very strange way!


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

Yes good idea.


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.
No version at this time, perhaps next release of EBModel, but really no problem to change something to this. 


#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?

2 remarks about this:
1) You not need to do test if(appl_getinfo(APGI_VERSION))
you can only do
if(appl_getinfo(APGI_AESINFO, &short_name, &long_name,&arch_string, &status_string)) 
{
...blabla software do what he wan't about this informations
}
because appl_getinfo() return 0 if not avaible
2) For homogeneity with other appl_getinfo() there is no way to put pointer to appl_getinfo() this only short value, I think it's not a very good idea that we need do specific code in gemlib to manage this, no? I have start to think about 64bit system AES, this a very hard problem enough, with pointer, I'd like not add too much problems with AES, there is already enough! Second add pointer it's more problem with memory protection.
I have add a small modification too in appl_getinfo(), for ressource load capacity, I have already post here my need, without answer I have do this 

case 2: /* AES_SYSTEM */
pb->intout[1]=Getrez(); /* Getrez() */
pb->intout[2]=256; /* nombre de couleurs support‚s par AES object library stupide! */ 
pb->intout[3]=1; /* couleurs icones support‚es */
pb->intout[4]=1+2; /* 1-> long ressource as AES 4.0 define, 2->long ressources as Interface define */ 
break;

I need this because I have correct Vision that use a very buggy version of xrsrc! that have a lot of trouble with MyAeS (I don't know where this version was found!), and because I didn't wan't correct this part of code, I wan't only use standard rsrc_load() when present, actually I have force to do this and it work perfectly, but of course on other system like NAES it crash! If you not see any incompatibility (I notice myself nothing) it could cool that we do the same.

Regards
Olivier