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

[Odd Skancke <ozk@atari.org>]

ons, 13,.07.2005 kl. 21.12 +0200, skrev Arnaud BERCEGEAY:
> 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.

 This means you think it will be better to add new suite of calls for
the new operating mode?

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

 Ofcourse not.

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

 For me, a library is a package of functions, all with ONE GOAL.
Different libs, different goals. Gemlibs' goal is to provide AES call
bindings, libjpg goal is to load/decode/put image into an arbitrary
bitmap, libgif/libpng, etc. etc are there to do one thing. Load, decode
and output an image into an arbitrary bitmap. An editbox library should
only provide an api for editing the text. editbox ouput should be just
the same as for any other libs that do graphical output, into an
arbitrary bitmap. Then the host-system, or the user (.app), decides what
to do with the output. These are what I call libraries.

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

 Yes, and this is fine, as long it stays within its goal of being an AES
library.

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

 Yes. And?

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

 Yes, and this is most probably a lib that is meant to make users of it
portable, right?

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

 I'd bet that libs that use the AES itself uses a gemlib.

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

 Why? Do you want a situation where libs enable/disable features on
behalf of the user (.app)? This sounds like disaster to me, having the
libs do such things by itself without the application knowing it.

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

 Your choise.

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

 Sad reading...

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

 The should be only one 'part' knowing and administering the GUI under
which the application runs. If all libs do their own thing, using the
AES like described, it sounds like a disaster to me. Definately this
design kills any new development in the AES.

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

 Well, I'm sure it is a good feature. So apparently we'll never agree.
What next? I will keep on developing WCOWORK. Apps I myself write in the
future will definately use this feature.

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

 The idea is here to stay, be sure of it. Why is the implementation bad?
Because it redefines existing AES functions? Well, there is a reason for
that too, you know, and that is done so that the two modes cannot be
mixed. Now _that_ would create confusion.



 Odd Skancke