From mint-bounce@lists.fishpool.fi Wed Jul 20 22:33:02 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Date: Wed, 20 Jul 2005 22:33:35 +0200 From: Jo Even Skarstein Subject: Re: [MiNT] WCOWORK implementation : conclusions. To: MiNT mailing list Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: joska@online.no 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=2.1 tagged_above=-50.5 required=7.0 tests=BAYES_00, RCVD_IN_SORBS X-Spam-Level: ** > -----Original Message----- > From: mint-bounce@lists.fishpool.fi > [mailto:mint-bounce@lists.fishpool.fi]On Behalf Of Arnaud BERCEGEAY > Sent: Sunday, July 17, 2005 11:15 PM > > I've carefully read all the posts in this mailing list related to > WCOWORK. > Please read carefurely this one. I've read it. To me it seems like you misunderstood Ozk a bit. He's not against using libraries, he just want those libraries to be properly designed and implemented. Some of the arguments against WCOWORK are just plain silly. E.g. "WCOWORK-apps" and "old" apps can't exchange window rectangles with each other. This is just silly. Of course they can. If you design a program and want to exchange rectangles with another application, you have to know what kind of data the other application deals with! What kind of rectangle does it need? The work area? The outer border of the window? You have to know this, regardless of WCOWORK or not. Another variant of this argument was related to WINDOW and WINDOM components. It was claimed that WINDOW will get all confused if some components use WCOWORK and other's don't. If this is the case then this is a weakness in the design and specification of WINDOM (remember, all protocols and interfaces must be clearly defined and documented), or a result of sloppy programmers who doesn't read and respect specifications. > About the simplification for programmers. > > I see two kinds of GEM developers. > > 1. old scholl developers that re-invent the wheel on each development. > When such developper want to develop a new application, then he copy 'n > past another application and change what need to be changed to make the > new application. Old school? I suggest you read up on some "old school" material, e.g. some of the stuff Donald Knuth wrote in the early seventies... > 2. intelligent/lazy developpers that re-use already proven-to-work code, > so that they don't have to redevelop anything for a new > application : the > .C files developped contains only the code specific to this application. > All "common" stuff already developped are provided by libraries (windom, > woutlib, gslib...). You also have the third kind: Developers who thinks that The Ultimate Library makes things easier. You know, the kind of library that does everything for you. Every time these developers needs something new - like a easy way of displaying a JPG in a window - they add a function called DisplayJPGfileInWindow(char *file, WINDOW *w, int x...). Soon this library contains hundreds of structures and functions which really doesn't work all that well together. IMHO the correct way to develop The Ultimate Library (say, a library to make it easier and faster to write AES applications) would be something like this: - One library that handles windows, forms and events. - One library to load and decode JPEGs to device dependent or independent VDI bitmaps. The application will then link with both libraries, use the JPEG-library to load and convert the JPEG, write a small callback-function for the forms-library that blits the bitmap to the screen. You want to load GIFs in additon to JPEGS? Write a library to load and convert GIFs as well. Or perhaps you want to print the images instead of displaying them? Re-use the JPEG-library and blit the bitmap to the printer device instead of the screen. What you *don't* want is a JPEG-library that is dependant on the forms-library! This is not re-usable code! As you probably know by now, I don't like The Ultimate Library (and no - I'm not saying that WINDOM is "The Ultimate Libray" ;-). > You can class me (and windom users) in the 2nd type of > developpers. AKAIK, > toswin is in the first type (that application has its own > evnt_multi loop). TosWin use a GEM-library, although a bit outdated one. But I really don't see the problem in using evnt_multi directly in the application?? Evnt_multi is very easy to use, I always do something like this when I play around with GEM programming (pseudo code): do EVENT e; evnt_multi(e); quit = do_event(e); until quit do_event() is my GEM-library's event-handler, and once I've created and opened any windows and forms used, this handler will take care of everything for me. In my own little forms/events-library, every window, form and every object in every form can have both variables and callbacks attached. Hell, I could put the above five lines in a function and call it "do_application" or something like that, and just called that function from my programs, but then it would be trickier to analyze and intercept events before they're passed onto the event-handler. Of course, there are many different approaches to this (like using user-defined callbacks in the event-handler, and call these before the events are processed by the handler. I sometimes do this as well.), each with it's strengths and weaknesses, but I really can't see why calling evnt_multi is "old school"... > If the features introduced in the AES is already provided by high GEM > library, then the benefit for programmers (2nd type) does not exist. The > only consequence is that developper of library have to work on their lib > to support the new AES feature... all that to have exactly the same > feature ? I see it the other way - why link 20Kb to each application to get e.g. multipage forms and multiline editfields when you can implement these as new objects in the AES? I see a lot of references to MagiC (don't break MagiC compatibility!!) here, but what did Andreas Kromke do? He introduced a set of extended objects just for this reason!! Underlined characters in buttons and boxes, hotkeys, frames, "HELP"-button... And what's worse, he implemented them by misusing some of the already defined bits in the OBJECT structure, thus rendering these useless when used as defined by Atari. Did I hear "compatibility"?? I sincerely hope Ozk continues his work and adds more functionality to XaAES. I want to see the above multipage forms and multiline editfields for example. Now that's something that will significantly simplify development of useful applications! Now, if I only could get my dead Milan fixed I could start programming again... Jo Even