From mint-bounce@lists.fishpool.fi Fri Oct 29 00:29:32 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de From: Henk Robbers To: mint@fishpool.com Subject: Re: [MiNT] Fpoll() in GEM programs Date: Fri, 29 Oct 2004 01:13:16 +0200 User-Agent: KMail/1.5.1 References: <417CD550.80306@atari.org> <200410280115.29861.h.robbers@chello.nl> <20041028084227.K3028@muecke.local> In-Reply-To: <20041028084227.K3028@muecke.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410290113.16683.h.robbers@chello.nl> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: h.robbers@chello.nl 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: Yes, hits=6.2 tagged_above=-50.5 required=3.8 tests=AWL, BAYES_00, RAZOR2_CF_RANGE_51_100, RAZOR2_CHECK, RCVD_IN_SORBS X-Spam-Level: ****** X-Spam-Flag: YES On Thursday 28 October 2004 08:55, Frank Naumann wrote: > Hello! > > > A good AES application should have only 1 waiting point, > > which is its central evnt_multi. > > > > My suggestion would be another event bit: MU_SELECT > > and a direct response mode bit: MU_DIRECT_RESPONSE. > > if the bit is set and there are no events, evnt_multi exits with > > zero event. !!! Unless a timer event is set, in which case the app > > is suspended until any event occurs (including of course timer). > > > > With MU_SELECT you have a way of getting filehandle or socket events > > the AES way. > > I aggree with with you but I rather vote to introduce a new evnt_multi AES > system call for that. Applications that are aware can use the new system > call and there is no compatibility problem. Internally XaAES only need to > wrap old evnt_multi to the new one. The new evnt_multi can also be > designed a bit better in this case :-) > Yes, you are right. I would call it evnt_omega ;-) And I would also say that it could be designed immensely better. It would be a good opportunity to extend the event mask to 32 bits. The event data can then simply be passed as a structure of 32 pointers to event data structures, each with plenty of reserve. To other people: I agree that the GEM world must be kept completely separate from the Unix world. This means especially: handle every interactivity by typical GEM solutions. GEM must be kept consistent. If you dont, why not just leave it and play Linux/Qt/Motif/Trolltech KDE/GNOME/Tcl/Tck/X11/X12/X66 and whatever available on fast machines. It is important that it is possible for a GEM program to do, for instance, socket like things in a GEM way. This makes GEM programs independent from a Unix background. Originally GEM was designed to be platform independent. Keep it that way. Some day, someone wants to port XaAES to a handheld or a mobile phone or his HIFI centre. ;-) Now XaAES is GPL and usable, dont hesitate to design new functions. That's what it is all about, that's why I bothered to spend almost 3 years on it. I certainly didnt want to conserve a museum piece. -- Groeten; Regards. Henk Robbers. mailto:h.robbers@chello.nl http://members.ams.chello.nl/h.robbers/Home.html Interactive disassembler: TT-Digger; http://digger.atari.org A Home Cooked teXt editor: AHCX