Re: [MiNT] WCOWORK implementation : conclusions.

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Mon, 2005-07-18 at 10:20 +0200, Petr Stehlik wrote:
> if I am wrong). By not reinventing the wheel Arnaud means that you
> 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, and there are pros
and cons to each.  I'm afraid no one seems the disadvantages.

Libraries, static or dynamic, have a way of being incredibly general and
possibly bloated, or they get that way over time.  They can also force
the programmer into a certain way of doing things that may not be
optimal.

> to imagine that it really is all sorted out for you when you're windom
> user. And Arnaud cares because it would be more work for the library
> maintainers if these new modes would have to be supported (for no
> apparent gain).

What I find odd is that windom is the only Gem lib to survive.  There
was a couple being developed that I used to read into a long time ago.
And the point is that windom is for old systems.  It doesn't have to
support a new mode if it doesn't want to.

> 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? The Windom clearly should help
> application developers to be more productive. I think it would be smart
> to use work of others and build apps on top of libraries. That is the
> one of the main points of FOSS.

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.

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.
This ensures better encapsulation since library A that expects WCWORK to
be ineffect can't change how the AES works for library B.  While one can
argue that library A and library B shouldn't both be making GUI calls,
and likely be correct, the argument of encapsulation still holds.  Start
off with something robust and correct in its own right that doesn't have
problems with another person's design ... don't just bash the design
that its not compatible with it!