Re: [MiNT] WCOWORK vs WINDOM for components

[evan@coolrunningconcepts.com]

Quoting Mark Duckworth <mduckworth@atari-source.com>:

> stuff I don't understand yet so I don't understand the specific
> advantages to not changing the api, yet I believe they are probably
> there.  In fact, I'm willing to bet one of the reasons to do it this way
> is because it's simple and clean cut.  If you change the api, then every

You can't say that you don't understand it, and then claim that it is 
simple and
clean cut.  You can't tell me you aren't qualified to make an opinion, and
follow it with something you claim as a fact.

> gem lib will probably need recoded or recompiled to work at all with
> xaaes still.  sounds stupid to me and very bad for our specific
> community.

Nothing will have to be recompiled to work with XaAES.  This never has 
and never
will be an issue.  Nor is it possible to make the change to WCOWORK within
GEMLIB.  Thats just absurd!  There are fundamental differences that the
application programmer would have to be aware of.

> Most people code with a GEM lib of some sort.

The existing GEM libs will work, its the application developer that has 
to make
a conscious change, and then ONLY if the new mode is supported by the
developer.  Otherwise, everything works as normal.

> GEM Lib supports WCOWORK
> All apps under it support WCOWORK then... The API of the GEM libs can
> change if that desire is there and most likely it will be.

No ... this is completely wrong.

> And I definitely don't think that we should behave as though Windom is
> the only lib out there.  I have chosen to use Windom but MANY others
> have not!  This obliterates all the work lp has done on his GFA gem lib,
> It's not good for cflib and all the other libs out there.

UHmm ... Windom is the only one that has been mentioned as implementing new
features beyond the traditional set of libs, such as a component API.  
The idea
of multiple libs in a component system, possibly dynamically loaded with a
multitude of designers is what brings in the issue of code modularity, 
and that
is where the problem lies.  Static libs and applications with 1 
designer aren't
a problem no matter which way you decide to code it.

> I can't say for sure whether I think the subwindow functionality should
> belong in the gemlib or the aes but I trust ozk to make that decision.

To do exactly what Ozk wants, this would have to go in the AES as his 
goal is to
have multiple processes as the component module.  I don't agree with 
this design
decision, but I wish him all the luck in his research.

> Even if he's proven wrong later, what's the big deal?  We can change..
> We're not a static binary only closed environment.

Uhmm .. Atari is more static binary than any other system out there.  We don't
have dynamic libs.    I'm not saying thats bad - just that your statement is
odd.

> Please.. end this for the sake of everyone's sanity.

Uhmm .. maybe you haven't been reading, but I thought my last email to 
Ozk made
it clear that we had come to some understanding.  Not an agreement per se, but
I believe I understand the reasonings behind his decision.  I don't personally
believe its the best way to go, but its not important right now.   I hope he
continues his research into WCOWORK and how it reacts with other types of
applications.   I may likely use it myself.

The real question here is how can so many people like yourself, 
support, or not
support this mode, when you clearly have no understanding of what the issues
are or how it works?

-- Evan