Re: [MiNT] WCOWORK vs WINDOM for components

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

Hello,

> > (IMHO) because this new xaaes feature is something that windom  
> > developpers
> > already experience for years.
>
>  I didnt know that. What new XaAES feature do you mean?

merging of differents "objects" (Text editor and HTML viewer for example)  
in one window. That is frames and inplace drawing.

>  I didnt know windom could do OS housekeeping needed to make this work
> smooth.

I don't know if it's ironic or if you sincerely didn't understand my post.

> However, the IPW idea was not the real discussion,

True.

> WCOWORK was.

True, and i try to understand why WCOWORK is needed, what's the benefit  
behind this implementation. This implement introduce some  
incompatibilities, so i'd like to know if the benefit is enough to support  
this feature. I'm sure you haven't introduce WCOWORK just for the fun to  
break compatibility... And i hope you have others ideas than just  
"simplify a bit xaaes-only applications that doesn't use libraries". In  
your answer to Olivier, you post some very nice ideas to justify why we  
have to use WCOWORK (this is what i ask from the begining of this tooooo  
long thread).

To justify WCOWORK, there is only the feature already describe (merging of  
different objects). I'm not speaking of the implementation, just the main  
idea.

> > We (windom developpers) find out that "framed" window in windom (wich  
> > is very
> > similar to what you have described in this ML) was not flexible and  
> > powerfull
> > enought, and after hours of discussion, thinking, argmentations, we  
> > conclude
> > that we missed a COMPONENT mechanism, and we spend a lot of time to  
> > define what
> > a COMPONENT should be and what it should not be. At the moment, we are  
> > about to
> > deprecated the "frame" feature because a COMPONENT is much more simple  
> > to use
> > and develop, and it's much more powerful and flexible, only advantages !
>
>  I can think of several reasons why this conclusion was made. One being
> the fact that windom is a library, not part of the OS.

Is that ironic too ???

I wonder if i must keep replying to this post... Your argument if for sure  
not valid !

>  I have found out that there is no room for any further development of
> XaAES. Reason I say this is that every new development goes on outside
> the AES kernel, in the form of libs, etc.

NO !

Stuff shall be done in the AES, and other stuff should be done in the  
user-space in libraries for example. I know we disagree on the scope of  
AES, and that's why i didn't speak about it.

I just tried to give you some tips if you want to introduce the feature  
discussed in xaaes (i haven't written in that post that i don't want xaaes  
to have this feature)... If you don't want themm, just ignore them ! Then  
i'm sure you'll find the same limitations and pb that we (windom  
developpers) have found.

> And when new features like
> WCOWORK cannot even see the light of day because "windom already have
> it",

Very wrong.

If you introduce a feature supported by windom "because of AES lack", then  
i'll try to support it in windom without hesitation. Frames in window may  
be one of them (windom have its own routines to draw and manage sliders  
which cannot be consistant with the AES because of the lack of AES).

> I no longer see the point. New features seems to belong in
> libraries. I dont agree,

You're right :)

> All new development for our platform seems to be
> centered around libraries.

This is very wrong. New features NEED the support of the AES... and new  
AES features need the support of application to be widely spread. Let's  
work together.


best regards,
Arnaud.