Re: [MiNT] WCOWORK vs WINDOM for components

[arnaud.bercegeay@free.fr]

Hello,

I'm offline most of the time in july and august, so it's very hard for me to
read all the posts, and impossible to reply.

BTW, i read so many wrong statements that i'd like to reply to some key points.

> I trust Ozk 100% to have good reasons for not wanting to play the game as
> you are suggesting. When it comes to implementations in FreeMiNT and its
> components, I do put my faith in Frank Naumann and Odd Skancke, since they
> (to a very, very, very large extent) are the ones who are making it all
> happen.

Yes, they are the main developpers of freemint+xaaes, and for sure they know
very well their job, but do you want an OS without applications ??? They are
not the main developpers for applications, and for new xaaes features described
in this ML, a feedback and return of experience from developpers is needed
(IMHO) because this new xaaes feature is something that windom developpers
already experience for years.

First, i'd like to remember what is an "AES application". Most modern
applications uses libraries. Let's say windom and gemlib for example.

Then, the "AES application" (the file.app you double-clic on to launch) is
a package of them :

file.app = (code written by the developper) + (windom.lib) + (gemlib.lib)

If one wants to use a "wout" window, then the executable will be

file.app = (code written by the developper) + (wout.lib) + (windom.lib) +
(gemlib.lib)

And file.app runs over the AES (and GEMDOS and VDI...)

Now, if one or several of these lib is provided as a dynamic library, then the
"AES application" will be (file.app) + (windom.ldg) + (wout.ldg) for example (3
files).

In the following, i'll speak about "well known" static libraries only... but for
sure, this applies too for dynamics libraries, but it's not the subject.

ok. Now let's talk about current evolution of xaaes. The "futur" for xaaes is to
introduce some mechanism (in xaaes) so that an application can have a framed
window with QED in one frame, and HW in the other (for example)... For that
purpose, a lot of things still have to be define (how data of one frame may be
exchange with data of the second frame because they are 2 different processes,
for example).

Well... if you had have a look at windom, then you saw that windom already
propose a "frame" API that answers all your needs. With the windom "frame"
feature, you can develop an application that open a framed window, with QED in
one frame and HW in the other. The mechanism is already here. The "long road"
target you plan for xaaes is something that already exist for years thanks to
windom. Developpers just have to use it !

In other words, what you tried to introduced in xaaes is a feature that already
exist for years in windom. If you still want to introduce this in xaaes, then a
good idea is to understand how windom works, and benefit of the experience of
windom (read on please)...

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 !

What's Evan has described (and what you labeled as too ambitious for a long term
purpose for xaaes IIRC) is just what windom developpers can experiment at the
moment by using CVS version of windom (i'm not 100% ok with the implementation
proposed by Evan, but the main idea is good IMHO).

To sum-up, i'm sure WCOWORK is a very bad idea. If you still not agree (after
having a look at windom), then go ahead, and in 2-3 years when applications
will start to really benefit from this feature, you'll see that you missed a
"real" COMPONENT feature and then you'll deprecated WCOWORK, and later, the new
component feature of xaaes will allow developpers to do exactly what windom
developpers can experiment NOW on every AES !  What a revolution !

Last note: the COMPONENT feature is still experimental in windom, we need to
test it more before stabilizing the API of COMPONENTs, but the first try of the
COMPONENT feature is here, and AFAIK it works.


Best regards,
Arnaud.

PS (don't expect any reply from me in July or August... i'm offline most of the
time, but i'll try to read this thread from time to time by using webmail).