From mint-bounce@lists.fishpool.fi Tue Dec 14 22:10:39 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] wind_xget() From: Odd Skancke Reply-To: ozk@atari.org To: mint@fishpool.com In-Reply-To: References: <1102967350.4922.11.camel@fedora> <41BDE81A.3080901@utbm.fr> <1102969299.4922.17.camel@fedora> <1102973255.4922.25.camel@fedora> <41BE9FFB.9030800@utbm.fr> <1103034081.4922.63.camel@fedora> <41BEF45B.4050808@utbm.fr> <1103045340.4922.74.camel@fedora> Content-Type: text/plain Date: Tue, 14 Dec 2004 23:09:02 +0100 Message-Id: <1103062142.4922.96.camel@fedora> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 (2.0.1-2) Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.8 tagged_above=-50.5 required=3.8 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: tir, 14,.12.2004 kl. 21.32 +0100, skrev Arnaud BERCEGEAY: > Hello, > > >> > 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 ? Correct ;-) The call from my point of view is like I wrote above :) > > It's ok for me. Good, I just checked in the changes, WF_FIRSTAREAXYWH should not be implemented in XaAES. > > 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. Okie, sounds find by me. Should we do so? > > 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. > Ok.. see my suggestion below for such detection. > > 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: Yes, value of APGI_AESINFO should be agreed on.. suggestions? > > 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]. Ok, as a way to detect which aes we can use intout[1/2] to contain a 4- letter ID, like 'MyAES' or 'XaAES' in addition to the above definition. This would make wind_get(WF_XAAES) redundant, and can be removed. So, aes_control[2]=3 (instead of 5) I was thinking that this ID could be put into the 'short_name' string in my original suggestion, but I think this is better. Opinions? > > 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); Yes, that sounds excellent to me :-) > > where > aes_name will be filled in with "OurAES" > aes_version will be filled in with "1.02b (25 dec 2004)" > > opinions ? I like it. With the addition of AES ID (which is a fixed-lenght AES ID) in intout[1/2] for appl_getinfo(APGI_VERSION, aes_name, aes_version, NULL, NULL); I really like this idea :) Regards, Odd Skancke