[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hello,


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?
It's better. Maybe it's not the best solution (i still don't know what the real goal we should soon see).
BTW, in WCOWORK mode, if you don't want an application to control the FULL area of a window, then wind_calc() shall return an error, wind_set(WF_CURRXYWH) shall return and error, etc... don't do things half so that application may get confused... 


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.


agree up to here :)


Then the host-system, or the user (.app), decides what
to do with the output.


No more agree.
why a library specialised to print strings in a window must not exist ? Because it uses AES functions ?
So cflib must be trashed because that "library" do some AES call ! same for windom ! my GEMSCRIPT library should be trashed because it manage AES message and send AES messages to other application by calling 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.


 Yes. And?
and it manages a window... and so uses AES functions and catches AES messages, but do not know if the underlying AES is in WCOWORK mode or not... or should this lib check that in each function ? 


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?


Don't understand your sentence :/


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.


yes.
All my AES/VDI stuff requires GEMlib now (including windom, and as a consequence all windom applications). 


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.
Or let the application doing such thing by itself without libraries knowing it. 


 If all libs do their own thing, using the
AES like described, it sounds like a disaster to me.
Libs do the thing they have to do, and they use for that purpose the AES API if needed. The pb is that the AES API is no more well defined (the definition of data changes depending on the WCOWORK mode). 


Definately this
design kills any new development in the AES.
Definately this design (variable definition of AES API) kills any new development in applications ;) 


 Well, I'm sure it is a good feature. So apparently we'll never agree.
If i correctly understood, you want XaAES to work fine with old application, You want XaAES to work fine with new applications compliant with WCOWORK, but you don't care if today and futur application we're working on no more work on XaAES... it's really sounds like a personal attack :( 


What next? I will keep on developing WCOWORK.
So, no need to discuss anymore ? It's what i understood at the begining, but now i'm sure. 


 The idea is here to stay, be sure of it. Why is the implementation bad?


double define of AES API.


Because it redefines existing AES functions? Well, there is a reason for
that too,
Ah ? please tell me (killing our work is not a good reason, please find another one)...
New functions to keep the AES API well defined is far better than actual optional change of AES API definition, and that way no more problem.
BTW, the WCOWORK stuff has it is now seems only half defined and the actual implementation seems to be a hack to me. I would like to have some more discussion and agrement from active supporter and developper before implementing what we have now. Then, it will be easier to perform the great move ! 


Goodbye ?
Arnaud.