Re: [MiNT] WCOWORK vs WINDOM for components

[jvalant@atari.org (YesCREW)]

On Sun, 24 Jul 2005 17:52:58 +0000, Odd Skancke wrote:

>  True.
>
> >
> > 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 !
>
>  I didnt know windom could do OS housekeeping needed to make this work
> smooth. However, the IPW idea was not the real discussion, WCOWORK was.
> IPW was just an idea, altho I thought a good one.


   Does anyone consider that we may not WANT to use Windom? So what if Windom 
already have "frame" feature? Coders will be force to use Windom or what? 
"Windom or fuck off" That is NOT right. Leave libs to those who want's to use 
them. Offer other possiblity (AES API) to those who dan't wanna use Windom 
(ar whatewer lib there will be).

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

   Another one is that they want to push Windom upon everybody. Windom should 
became the new Atari standard! Supremacy issue.

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

   Revolution indeed. By using Windom. No room for rest. Also "Linux does 
that, Linux does that too, Linux use libs, any modern app use libs" is not 
revolution, it is COPYing. U maybe did not notice: OS is called MiNT, hardware 
is called Atari.



>  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. And when new features like
> WCOWORK cannot even see the light of day because "windom already have
> it", I no longer see the point. New features seems to belong in
> libraries. I dont agree, but I have to give in because if the last
> remaining scene wont use new feature, I dont wont to spend time
> developing them. The fun is gone.

  OZK: Windom authors are NOT scene. More people already said they don't wanna 
be forced to use Windom. I agree with them. Let the people (not involved in 
Windom and etc..) show what they prefer. Personaly, AES API is the way, even 
more, since libraries can still be used... If needed, u can branct to OzkAES 
or whateve, or Evan can branch to EvanAES, but offers us a choice.. or we can 
just all migrate to Windows...


   Janez