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

[Odd Skancke <ozk@atari.org>]

tor, 14,.07.2005 kl. 00.00 +0200, skrev Arnaud BERCEGEAY:
> 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).

 WCOWORK is a new operation mode, and it is not mixable with the
existing FULL-area orientation. Therefore, I dont think we need a new
suite of AES functions. WCOWORK aware applications will know this.

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

 Agreed on wind_calc() should return error. I dont agree wind_set
(WF_CURRXYWH) should return error. Its in the name CURR as in current.
Do not confuse CURRENT with FULL. Its just that normally the AES was
FULL-area oriented while in WCOWORK mode, the AES is WORK-area oriented.
WF_CURRXWYH changes behaviour thereafter. If anyhting WF_WORKXWWH should
return error, as this mode looses its meaning.

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

 I'm no lib expert, but I think Evan had a point saying that if such a
lib actually uses the AES by itself, it is not nicely designed. It
should prepare output for the user of the lib, and the user of the lib
can choose what to do with the output.

 Besides, under MiNT there is the /pipe/alert to wich application can
write important notes, and the system decides how to show it. Ofcourse
this is not supported under MagiC or SingleTOS, so it is not used.

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

 cflib is an AES library. It is not trying to put an editbox into a
window. It is not showing images.

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

 I would think such a lib would return the size of its output for the
user. Then the user would use, for example, windom to create the window,
and use its features to install a function for WM_REDRAWs that calls the
the draw function of the form library to draw the form inside the
window. Having two libs using the AES in this scenario is just plain bad
design. Doesnt matter if the libs output is a form or a text or image or
mplayer. Neither should NEVER go to the GUI by themselves.

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

 Then this is a badly designed lib.

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

 Again, only one lib should deal with the GUI. In your case this would
be WinDom. This is a window library, and only those functions should
deal with window specific stuff, like telling the different other libs
to redraw its output when needed, etc.

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

 Well, if, for example, libeditbox or libplaympeg or whatever goes to
the GUI for itself, those libs are just plain useless, and not portable
and not usable at all in apps.

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

 Variable definition? There are two different, non-mixable operating
modes. What is so hard to understand here?

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

 If the design of your applications and libraries are like the above, I
think they better stay on old OS's anyway. Thats where you want to be
with such design.

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

 Ofcourse we can discuss, but so far the only thing I hear is that
because of idiotic library design, WCOWORK mode cannot be used.

> 
> >  The idea is here to stay, be sure of it. Why is the implementation bad?
> 
> double define of AES API.

 Again, two different operating modes. If we create new functions for
WCOWORK mode, all the original functions would have to be made
unavailable. That is not necessary, because the application explicitly
have to enable WCOWORK mode.

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

 Killing your work? I'm not interested in killing your work. Ok, listen
closely now, ok? You can use either WCOWORK mode, or standard mode, but
NOT both at the same time. ok? See? Perhaps I'm thinking you know more
about AES programming than you actually do?

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

 No. Reasons above.

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

 The implementation is is not a hack, but you are right it is far from
complete. I was hoping for constructive critisism instead of being told
it is useless because the way you design your library. While your idea
sounds good, please take a moment to reconsider this "libthis and
libthat both use AES indipenant of the user, the (.app)" Bear in mind
that even WinDom is told by its user (.app) what to do for each
individual function it provides (and this is correct). In WinDom linked
applications, only WinDom functions should use the AES. (not counting
gemlib here, because its just a binding lib, not providing functions
like windom) If the application is an image viewer, the application has
to provide the glue functions between WM_REDRAW's and output of the
image rendered by another lib. Hopefully you understand this.

 Furthermore, talking about WCOWORK mode doesnt seem to lead anywhere,
and so i dont think WCOWORK will be used by application authors
immediately, not until they see the benefits in existing applications.
Therefore I will use TosWin and Qed to conduct experiments.




 Odd Skancke