From mint-bounce@lists.fishpool.fi Tue Jul 19 09:39:55 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] WCOWORK implementation : conclusions. From: Petr Stehlik To: Evan Langlois Cc: mint@fishpool.com In-Reply-To: <1121724783.17671.12.camel@taro.coolrunningconcepts.com> References: <200507180121.43340.maurits@bassment.nu> <1121674805.1784.20.camel@joy.sophics> <1121724783.17671.12.camel@taro.coolrunningconcepts.com> Content-Type: text/plain; charset=ISO-8859-2 Date: Tue, 19 Jul 2005 09:37:44 +0200 Message-Id: <1121758664.2044.13.camel@joy.sophics> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: joy@sophics.cz 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=BAYES_00 X-Spam-Level: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id j6J7dt6u010629 Evan Langlois píše v Po 18. 07. 2005 v 17:13 -0500: > > simply write your program logic only and don't bother with the GUI stuff > > as it's all handled by the library already. > > Part of the point was about static vs dynamic libs no it wasn't. > What I find odd is that windom is the only Gem lib to survive. previous GEM libraries didn't have good documentation in English. > And the point is that windom is for old systems. this is completely wrong. > > I'd say that the question is this: when updating old program, or writing > > a new one - will you write it with event_loop and all that crap while > > using WCOWORK that simplifies it a bit (and breaks the compatibility > > with other, older, dead-ish AESes), or will you go for a high-level GEM > > library that encapsulates it all? > Or will someone make a new library that uses WCOWORK and ONLY WCOWORK. > All the cruft and extra code for compatibility can be removed. No more > code sitting there to emulate toolbars for OSs that don't have them, > because you KNOW the OS will have them if it supports WCOWORK. You CAN > have a high level library that is smaller and faster because of WCOWORK > improvements. Well. I've spent 20 minutes thinking how to reply to this paragraph. Your idea of making a new library because of some new XaAES mode is so insane that I will have to leave it unreplied. > Now, my problem is that I don't think this "mode" is the best way to do > it. I'd rather see it done with new calls that are more flexible than > the existing ones, and only have WCOWORK available with the new calls. I tend to agree with this although I must admit that it breaks the Ozk's idea of simplifying old event multi programs simply by removing bunch of full<->work logic :-) But that idea itself was not good anyway as I tried to point out in my earlier mail. Petr