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

["Arnaud BERCEGEAY" <arnaud.bercegeay@free.fr>]

Hello,

> > > and "Dont make
> > > new things as they wont work on other AES's".
> >
> > This has never been one of my arguments.
> >
> > If we need to break backward compatibility to introduce usefull new
> > feature, then go ahead !
>
>  This is not what you have stated before, but ok

Ok. I'll try to be more explicit then. It's something that seems evident
to me, and i'm sure we agree on the subject... BTW, it's always good to
explain and erase any misunderstanding.

For me, "don't break backward compatibility" is not a *requirement*. This
sentence is much more a recommandation or a wish (i'm more sure if it's
the good word). If a new feature is implemented in the AES, then we have
to design the new feature to keep backward compatibility with AES API if
possible. Of course, old applications that doesn't know anything about the
new feature won't use it, it's evident...

Let's take an example. Imagine that we need another wind_set() mode for
the feature. The idea is to choose a free number for this mode, instead of
using for example WF_NEWDESK because for example WF_NEWDESK is deprecated
when the new feature is enabled.

It's not good to introduce incompatibilies "just for the fun" if we can
introduce the new feature without breaking the compatibility.

>  Ok, here you should really take a second and consider what these
> components should know about. In my optinion such libraries should only
> know the cooridnate of where to output 'its function'.

I do not agree.

For me, a library is just a package of functions, and for sure, they can
use AES functions (this is the only aim of mt_aes). The advantage of
libraries is that functions used by several applications may be developped
only once, and then used by several applications.

Windom is one of these libraries, and windom intensively use AES functions
!

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.

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

You can clearly see that such libraries uses AES functions to manage the
window in charge.

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

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.

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.

> > This modularity feature mechanism is still under construct. The first
> > piece was gemlib 43. Now, we're working on COMPONENT stuff and  
> > MT-windom.
>
>  This sounds like overkill. These libs should not be part of a gem
> library.

I don't understand here; if your reaction if for "gemlib", the work done
was the introduction of mt_aes in gemlib, to allow the use of AES
functions in another piece of code than the application.

>  You think a new set of functions is better?

Well, i'm still not sure to have understand very well the goal of the
feature. On one side all deals with WORK area because application no more
have to know about FULL area, and in the other side new wind_xget() modes
allow to do the conversion between WORK and FULL area (what for ?)... and
at the same time you remove the function to change the FULL area of a
window (wind_set(WF_CURRXYWH)).

So i don't know if the best is a new set of function or not. All i'm sure
is that this optional feature is not good.

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.


best regards,
Arnaud.