Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

fre, 22,.07.2005 kl. 17.27 -0600, skrev evan@coolrunningconcepts.com:
> Quoting Odd Skancke <ozk@atari.org>:
> 
> >  Ok, then I just didnt understand what you wanted. I still wonder how
> > you will implement this.
> 
> Simple.  I won't.  My goals will work with or without WORK area centric 
> API.  I
> simply am not working on XaAES at this time.  I have other things to work on
> that I plan on having cross-platform well beyond MiNT.

 Ah, what have you done so far, then? Any links I can find info about
your work at?

> 
> I would love to see a WORK-centric API added, and if it was, I would use it
> exclusively, providing that I had a guarantee that I could link with 
> other code
> that doesn't understand it.

 A lot of the other things that WCOWORK would open for could not be used
if there are chances the application mix the two orientations. This is
why. Lets take the simple example of themes. How do you make immediate
theme changes work reliably if the application can use the FULl extent
of windows in parallel to the WORK area? And how can you say that this
generates less complexity? I dont get that.

 Besides, linking agains code that is outdated in a new application is
not good programming practice. I would not even use this as an argument.
Besides, only one of the libs which application is linked agains should
be the GUI frontent, like windom. If other libs also uses  the AES, or
if windom dont know WCOWORK, the application simply cannot use WCOWORK
mode. Or, like someone said before, two libs, one knowing about WCOWORK
while the other dont .. I think this sounds so messy it isnt an argument
at all.

> 
> Perhaps if you told us why allowing both is so wrong, I would understand.  I'm

 Because there are functions/features the AES cannot make available if
the application can use both orientations. You do understand that if you
allow for both orientations, different api's, one window can be
controlled by both api's? This takes away the AES's control of the
window's exterior. This will create confusion for application authors
wishing to support functionality unlocked by WCOWORK.

> not at all saying that a programmer should toss both APIs together like 
> a mixed
> salad.  They can and should use the WORK mode exclusively, but I don't see why

 Well this is exactly what you are saying.

> you should force bad things to happen when you link in a library that doesn't
> know about WCOWORK if it can be avoided.

 If you are writing a WCOWORK oriented applications, you would have to
update the lib your using too. Otherwise, as I've said before, WCOWORK
looses its purpose. New application using old libs .. man, is this even
a valid argument? Does this mean XaAES and MyAES should work with libs
created in 1989?

> 
> You seem to think that something bad will happen if you allow both APIs, but
> even though I continue to ask you what the issue here is, you won't tell me.

 I've not said something bad happens, I've said that WCOWORK is rendered
useless. By that I mean the AES cannot trust the application to work
exclusively with WORK coordinates, and thus cannot do all the fancy
stuff discussed. Or do you want the old api to return error under these
conditions? What a mess. About complexity, allowing both orientations
would double the amount of api calls, double the amount of aes message
types, and for what? Nothing! Since there's a chance the application
uses the old api for a window created by the new api, the AES cannot
'open' for new features. Is this explanation good enough?

> 
> >  Well, the alternative you wrote about in another post is something I am
> > 100% will create complexity, confusion and complete mess. Since I cannot
> > understand how this will ever work, I have to let go. Now you can put
> > your actions where your mouth is.
> 
> Well, your review of my ideas is a bit late, and I wish you could go into more
> detail as to why you think that.  I think I've given you more respect than you
> are showing me.

 Your ideas are too heavy for me to ponder. I dont understand how you
can have such ideas and not see the havoc allowing for two different
orientations will create.

> 
> >> And "shut the fuck up" is hardly constructive.  When you say such things you
> >> only prove my claim that you are unwilling to work with other 
> >> people's ideas.
> >
> >  Not that I'm unwilling to work with other ppl's ideas, its just that
> > when these ideas are so wild, at least to me, I cannot participate.
> > Therefore I back out and hand it over to smarter ppl like you.
> 
> What is so wild?

 How about ideas that is a bit more down to earth? lets go small steps,
my limited capacity needs that.

> 
> >  How do you find time to write such extensive mails, then? Now you can
> > spend time implementing your ideas instead of pounding them into this
> > list.
> 
> Very true.  It seems I am wasting my time with the Atari.  All I get it people
> who are too emotionally attached to design things and compromise with each
> other.

 I have no problems making compromises, as long as the things we're
talking about is possible.

> 
> >  You need to show me how to do this. I dont understand how this can
> > work.
> 
> What exactly is the problem?

 See above.

> 
> >  You think you can have the application use both. I say that this will
> > make WCOWORK useless. You have the ball, you show us how.
> 
> Why useless?  I understand you want to restrict all applications to using just
> the WORK area, and that is the whole point.   This would simplify 
> things if ALL
> programs did it and the AES always worked this way, but that isn't the 
> case, and
> so the AES must do both anyway.  The question now is what feature are

 Again, this exactly the need for 'mode'. Since the benefits of having
WORK orientation will be killed by possible use of FULL orientation
simultaneously, I fail to see any other way of doing this.

>  
> we losing
> when someone mixes APIs and what is the end effect?   I've gone through it a
> few times in my head, and I don't think its as bad as you think.

 We will loose ALL features that depends on WORK coordinate orientation.
And then WCOWORK is useless.

> 
> >  If you look at the cvs log, you can find the date I added WCOWORK mode,
> > and revert back to that. Then you can start afresh with your
> > implementation.
> 
> If I were willing to do that, and I'm not, I wouldn't revert the changes.  I'd
> just move them into new functions instead of changing the existing ones.
> 
> >> You are being downright insulting.  You hardly seem willing to having an
> >> intelligent discussion.
> >
> >  I dont see any intelligence at all here, so sorry, I'm too stupid.
> 
> Again - this isn't the way you have a discussion.  You are being childish!

 You may feel that I am childish. Perhaps I am. I still dont see any
intelligence in your idea of allowing both, having new API, etc. etc.
Why is that?

> 
> >  If the goal was to keep the old FULL window coordinate orientation, I'd
> > agree. But my goal was to remove that completely, keeping it only for
> > backwards compatibility. I still think we'll be struggeling with the
> > FULL coordinate problems when you allow both, and implement new api for
> > WORK oriented calls.
> 
> OK - this is better.  What are the FULL coordinate problems, and why do 
> you feel
> that allowing both would continue the problem instead of slowly phasing 
> it out?

 Because of possible use of FULL area. By allowing this, one will NEVER
get it phased out!

> 
> >  and how many of todays app is linked against windom? This argument is
> > just....
> 
> More than the number that use WCOWORK!

 And MUCH, MUCH less than other apps out there. You're suggesting we
make changes that work 'half-way'?

> 
> >  I'm willing to see another point of view. But here I cannot agree with
> 
> No - when I try to discuss this you act like a child!  That isn't 
> seeing another
> point of view.   This is madness!

 I have read your point of view, and I have argued against it. Then I
get accused of forcing WCOWORK upon ppl, and not seeing others point of
view. Well .. what am I supposed to do when these views are downright
wrong? I'm not gonna agree just to keep the peace. All I have done is
claim that WCOWORK and FULL orientation cannot be mixed, hence keep the
same set of API. I would have hoped that ppl do more research before
they argue. I have nothing against healthy discussion, but when it come
down me forcing things on other, I loose interest.

> 
> > keeping FULL and WORK coordinate orientation active at the same time. If
> > there was a reason to keep the FULL orientation, I would not have
> > attempted WCOWORK at all. And adding WCOWORK is pointless if one still
> > wants FULL orientation capabilities too. This is the problem I had.
> 
> OK - why does it make it pointless?

 see above. I thought  this was obvious, tho. Perhaps thats my mistake?

> 
> >  IPW discussion is pointless now. We never got past WCOWORK.
> 
> Didn't like anything about IPW anyway.

> Tell you what - you and the Windom team continue your arguments with 
> each other,
> you can keep being a childish dictator of XaAES, and you can implement crazy
> ideas to further fragment the Atari user base until there is nothing left that
> anyone can agree on.  Compromises are for people not as smart as you, and
> everyone should just do as you say is right.

 Hmm.. you're not gonna take over XaAES?

> 
> I'll go back to platforms where people can discuss things intelligently and
> compromise and work together.

 Good work.



 Odd Skancke