Re: [MiNT] WCOWORK implementation : conclusions.

["Joakim Högberg" <gokmase@gmail.com>]

>> I've heard that such approach is a hack, a bad design, something idiot...  
>> What is idiot in the story : to help other developpers by providing a set  
>> of lib so that they don't have to re-invent the wheel for each  
>> developpement ?
>
> 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.

No you are not the only one. If things are coded as you say, it sounds like a 
messy implementation which is bound to make it hard to extend the AES API
in the future, if libs are accessing the AES while not being aware of what they are
doing, and for whom. That sounds more like total computer anarchy to me.

Having access to powerful libraries is of course a blessing, but if the design
ain't good I think it may prevent the AES from evolving, which would be the worst
possible thing.

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

No, that would IMO be the ideal way of doing it. Then any new features would be
available to all coders regardless of the programming language used. Just because
something is not of immediate benefit of "2nd type", that doesn't mean it is a bad idea.
I don't code in C, but you still don't hear me saying that Windom is useless.


>> For WCOWORK feature, there will be no advantage at all for developpers  
>> (only some hours of work for the library developper and some possible  
>> incompatibilities problem already explained).
>
> This is the problem, you refuse to the benefits, only whats 1 cm away
>from your noses.

Fully agree, this is almost getting silly.

>> If you want to detect that kind of application (ready for on the fly theme  
>> change), then just one bit is enought, just one bit for the application to  
>> declare it's a clean application that does not memorized AES data (size of  
>> border, etc...) : application asks the AES when needed. That kind of  
>> application do not need to be work with the WORK area of the window only.  
>> There no relationship between the two.
>
> 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 agree. There are enough bad implementations made in the past, we could
save ourselves many future problems by coming up with clean and solid solutions.


/Joakim