Re: [MiNT] WCOWORK vs WINDOM for components

[Lonny Pursell <atari@bright.net>]

on 7/23/2005 12:12 AM, evan@coolrunningconcepts.com wrote:

>> But needless to say Ozk explained to me my WCO is the way it is, and I fully
>> accept his reason for not considering my idea.  It made sense to me.
> 
> Could you forward it to me?  Cause I don't quite get the picture yet.

I did not keep the mails.   He also hit reply and thus his reply did not end
up on the list.  Maybe Ozk still has copies of the mails, I don't. Also he
stated more or less the same thing here on more than one occasion.
 
>> I still don't understand the problems with libs.. blah... whatever. If you
>> have an old lib, simply do not invoke the option for your app.  If you are
>> using windom, you should know what it is and isn't capable of??  As the
>> coder you have the source code??  Sure hope so.  Thus you simply DO NOT
>> invoke the WCO mode.  It does not magically turn itself on.  Windoms happy,
>> your app is happy, it runs as it did before and so on and so forth.  You are
>> making this way more complex than it really is.
> 
> You don't understand.  I WANT to use WCOWORK.  I like it.  But you cannot be
> guaranteed that you have the source for all libraries you link with.  There is
> something called "modularity", and if done properly, what one module
> does won't
> interfere with the other.  WCOWORK breaks that simple fundamental principle
> since as soon as you set that mode for one module, the API of other modules
> changes.  More advanced applications might have dozens of libraries and
> components and you shouldn't have to go through them all and make sure
> they all
> support WCOWORK to make sure you can use it.  The modular approach seems to be
> the correct approach.

This is a very simple concept.  If you suspect any one of your imported
modules cannot deal with WCO, then by all means do not turn the WCO mode on.
I have to question the validity of that question even.  If you are making a
program and you don't fully know what all the individual parts are capable
of or doing, hmm should you be coding in the first place?

> For any WCOWORK mode call designed to stop me from altering the FULL
> coordinates, I can take the FULL coordinates that I want, pass them to
> wind_xget() to calculate the WORK coordinates and pass that into the AES call.
> Now I just bypassed whatever the API change was trying to prevent.  So,
> why not
> just keep the original calls the way they were and give me new ones to
> use in my
> modules, so that programming can stay modular?   I've yet to see how changing
> the API over presenting new calls is a huge win.   I'm not being argumentative
> - just explain it to me!

It's my understanding that those calls are there for extreme reasons.  Like
if someone still wanted to force the windows out x/y to an even pixel
coordinate.  Yes they seem to defeat the purpose and if someone is going to
code in that manner I would suggest not turning on the WCO mode in the first
place.  You are only going to fully benefit from WCO if you stick to working
exclusively with WORK area coordinates.

-- 
Lonny Pursell    http://www.bright.net/~gfabasic/