[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] WCOWORK implementation : conclusions.
Quoting Odd Skancke <ozk@atari.org>:
I did not say WinDom is bad. I'm saying that if other libs TOO use the
AES like WinDom, the design of those libs are bad. Why? Because WinDom's
functions loose control. And this is the scenario you described when
saying that "one lib dont know what AES actions the other do". Terrble
if you ask me, and apparently I'm the only one thinking so. I'm being
outnumbered by a bunch, it seems and give up this discussion.
I mostly agree, but it is concievable that a library would want to
simply open a
window. Assume that windom will manage all the events for this window
and send
the library just redraws, and tell the library when the window is closed.
This isn't all that unclean, but the parameters to wind_create are
suddenly not
what the library expected if you are in WCOWORK mode.
This is why I made the suggestion to use new calls and not change
existing ones.
While programming guidelines should still be followed, and you
should not mix
and match, you still have the flexibility to include code that doesn't know
about WCOWORK into a program written to take advantage of it.
In lack of dynamically loaded libs, I think it would be a great idea to
include often-used or very good ideas into the AES itself. I'm probably
the only one thinking this as well.
I agree.
If this was the only goal, that one bit would be enough. However, the
goal is much greater. This is what I think has been the problem a long
time, inventing things that look great with some things, assuming that
more is never gonna be necessary. This kind of thinking is what create
things we struggle with today, like WDIALOG, AV_PROTOCOL, OLGA, SLB,
etc., etc. I'm not gonna follow that way of thinking.
I definately agree here as well, I just don't know if WCOWORK is really
the all
reaching solution that people are looking for, I've already detailed my own
suggestion on handling this, and it seems that the general approach would
already be familiar to Windom programmers. It would also be devoid of
the "3rd
party lib" problem - and yes, we can debate if that scenario is good
programming
or not, but as people keep telling me .. its what we have to work with. It
might make a worthwhile compromise.
-- Evan