Re: [MiNT] WCOWORK implementation : conclusions.

[Jo Even Skarstein <joska@online.no>]

> -----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