Re: [MiNT] [Mint-cvs] [FreeMiNT CVS] lib/gemlib

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Wed, 2005-07-13 at 21:12 +0200, Arnaud BERCEGEAY wrote:
> We can think of a library to manage forms. For example you call a function
> of the library with an XML file in parameter, and the the lib will build
> the form, open the window and manage all the events incoming to this
> window.

In most modern systems, each element of the form only knows its size and
relative position in respect to its parent element.  The form management
library would only need to know the working coordinates of the window to
position itself.  In no way should the form library be moving the window
its in, or anything else.  Its responsible for the form in, and nothing
else.

Modular programming isn't just about reusing code.  Its about doing it
safely.  The module is a box - each piece does its job, and doesn't
monkey about with someone elses job, and that is what you are
describing.

> Another example (that already exist) : WoutLib. This is a "windowed
> Output" library. For example, in your code you put "wout_printf("blabla
> %d", var);" and woutlib will open a window (if not already opened),
> display there the string, manage the window when opened (slider, scrolling
> when new text is displayed, etc...).

If people had implemented TOSWIN into the desktop the way I suggested 12
years ago, then such a library wouldn't be needed at all.  The moment a
printf is done, a window opens, no matter if its TOS or GEM.

The library for formatting strings should NOT be managing windows.
Thats a bad design! 

However, WCOWORK was supposed to work per window wasn't it?  So in both
examples, the piece of code handling the windows is the piece of code
that would or wouldn't set WCOWORK.  No problems.

> If the application, or one of the library (for example wout) enable the
> WCOWORK mode, then all other will get into troubles.

Not if its per application, and as I said - thats an aweful example.

> Ok, this is optional... so i choose to don't use it, and i'll encourage
> all developper to not use it if they want to use one of these libraries.

Gee thanks.  Maybe it will be Windom and not XaAES that gets forked.
Just recompile with the XaWindom library, and all the old compatibility
cruft goes away!
 
> For example, if you want to simplify even better the toswin code, you can
> let the "form library" manage toswin forms... oh! but it won't work under
> XaAES because under XaAES toswin enables the WCOWORK feature.

In a properly developed form library, this wouldn't be an issue at all.
The application's event loop still handles the AES events and messages.
A form library is as simple as finding the object being clicked on, and
then calling the function for that object and while the AES doesn't
support direct callbacks, its pretty easy to store your function
pointers with the object.  The library would be taking care of the form
and its contents - not listening to AES messages.

> Please don't misundertand me. I'm not saying that the WORK-only approach
> for applications is bad (if you want my feeling, i like the WORK-area only
> idea). I just say that actual implementation of WCOWORK is bad.

I'd say that it needs some work.