From mint-bounce@lists.fishpool.fi Sat Jul 16 00:24:46 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] GEM boost From: Evan Langlois To: Henk Robbers Cc: MiNT Mailing List In-Reply-To: <42D815C8.1020300@chello.nl> References: <42D815C8.1020300@chello.nl> Content-Type: text/plain Date: Fri, 15 Jul 2005 17:23:41 -0500 Message-Id: <1121466222.5412.46.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com 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=-1.0 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: On Fri, 2005-07-15 at 22:00 +0200, Henk Robbers wrote: > I like GEM very much. Although it looks like a little > tedious in its usage, once you have written 1 GEM program you > mostly have dealt with the issues for further GEM programs. Tedious? By comparison to what? GTK isn't any easier. > The main advantage of GEM over other GUI systems is that > it allows programs to be a single threaded multiserver. Almost all GUI systems have a single event loop if this is what you mean. > In other words: a GEM program can handle any number of windows > with a unlimited variety of content without the need for > threads. A situation that greatly increases reliability, > predictability and stability. How is this different from other systems? Except that GEM doesn't have a way to interface with file handles within its event system. This basically forces you to use threads, or use an inefficient polling method. So, you kinda got that backwards. > A GUI must really be part of the OS. The part that is > by far the most trustworthy part of any computer. I'd rather have the disk IO system trustworthy, interrupts, memory handling, etc. Otherwise the GUI doesn't have a chance. And who cares if your GUI goes haywire if your disks get corrupted? > XaAES will reach such a state of sophistication that > people might want to create a version of LINUX that offers > GEM as a alternative way of writing graphic applications > on modern computers. GEM doesn't offer the abstractions that modern programmers expect, and the VDI is seriously lacking on features. WCOWORK is a start, but I don't think its enough. > Be it only to get the full benefit of the amazing performence > of the latter. I gotta give it to you there. Its takes a really fast machine to beat an 060. My 500Mhz PC running Gnome is a dog. My 16Mhz STe may not have been the fastest at crunching numbers and compiling and such, but when it came to just getting stuff done ... I kinda miss it. I could actually USE the desktop. On Linux, the desktop is slow and clunky and I end up using the command line cause its faster.