Re: [MiNT] WCOWORK implementation : conclusions.

[Petr Stehlik <joy@sophics.cz>]

Evan Langlois píše v Po 18. 07. 2005 v 17:13 -0500:
> > simply write your program logic only and don't bother with the GUI stuff
> > as it's all handled by the library already.
> 
> Part of the point was about static vs dynamic libs

no it wasn't.

> What I find odd is that windom is the only Gem lib to survive.

previous GEM libraries didn't have good documentation in English.

> And the point is that windom is for old systems.

this is completely wrong.

> > I'd say that the question is this: when updating old program, or writing
> > a new one - will you write it with event_loop and all that crap while
> > using WCOWORK that simplifies it a bit (and breaks the compatibility
> > with other, older, dead-ish AESes), or will you go for a high-level GEM
> > library that encapsulates it all?

> Or will someone make a new library that uses WCOWORK and ONLY WCOWORK.
> All the cruft and extra code for compatibility can be removed.  No more
> code sitting there to emulate toolbars for OSs that don't have them,
> because you KNOW the OS will have them if it supports WCOWORK.  You CAN
> have a high level library that is smaller and faster because of WCOWORK
> improvements.

Well. I've spent 20 minutes thinking how to reply to this paragraph.
Your idea of making a new library because of some new XaAES mode is so
insane that I will have to leave it unreplied.

> Now, my problem is that I don't think this "mode" is the best way to do
> it.  I'd rather see it done with new calls that are more flexible than
> the existing ones, and only have WCOWORK available with the new calls.

I tend to agree  with this although I must admit that it breaks the
Ozk's idea of simplifying old event multi programs simply by removing
bunch of full<->work logic :-) But that idea itself was not good anyway
as I tried to point out in my earlier mail.

Petr