Re: [MiNT] WCOWORK implementation : conclusions.

[Odd Skancke <ozk@atari.org>]

fre, 22,.07.2005 kl. 15.39 -0600, skrev evan@coolrunningconcepts.com:
> Quoting Odd Skancke <ozk@atari.org>:
> 
> >  Ok, come up with a different sceme then. What goals do you have? What
> > goals to you want to see?
> 
> Already told you and you ignored them.  I laid out completely my ideas 
> on how to
> solve this by using a new set of calls, and new alternative to 
> evnt_multi().  I
> have then asked you TWICE after that for your comments.

 Ok, then I just didnt understand what you wanted. I still wonder how
you will implement this.

> 
> >  And why is this unclean? You think non-WCOWORK aware apps will see this
> > api change? This is why its ONE or THE OTHER.
> 
> 1 - Existing apps use the old method, period.  Can't change that.
> 2 - New apps should either
>      a - use new calls, free to link with other libraries that use the older
> calls.  There is no conflict sense older AES calls return the same data they
> always have, like #1 above.  If the new calls exist, any library is 
> free to use
> them regardless of whether or not other libraries linked with the application
> uses them.  New calls return WORK based coordinates for events and take WORK
> based coordinates for parameters, old calls stay as they are.
>      b - change existing calls, with a MODE that determines the behavior.
> Libraries not WCOWORK aware can't be linked, and if they are aware they must
> somehow determine which mode the application is using.

 I love to see this implemented. I hope you implement this as soon as
possible. I could not figure out how to do this in a clean way. The idea
of new apps linking to 'old' libraries just sounds plain stupid to me.
But you'll show us, I'm sure.

> 
> I'm thinking a is the most flexible and compatible, and we get all sorts of
> future expandability possible with the evnt_multi() replacement that we can
> take advantage of as soon as someone gets the change to implement it - the API
> is kept very open to enhancement.
> 
> >  All I hear is complaints about what is not possible, this or that. I
> > have not been given other working alternatives. All I've been given is
> > "this may work without WCOWORK mode", "that could probably work too".
> > Single issues are looked at instead of the whole picture. Give me a
> > working alterative then, or shut the fuck up.
> 
> I gave you an alternative - if you mean by "working" that I have to 
> code it and
> then add it to CVS without asking anyone elses thoughts, then you really need
> to rethink how things work.  People come to a consensus about how 
> things should
> work and THEN implement it.  You don't make the change and then tell everyone
> they don't have a working solution when they think your method is sub-optimal.

 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.

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

> 
> > find the complexity too great. And for what? What do you gain by
> > allowing both FULL and WORK area coordinates being used? Nothing but
> > trouble if you ask me.
> 
> Uhmm .. complexity?   See above.
> 
> >  Then I suggest you implement your working alternative, and let me know
> > how it works out.
> 
> I'm really busy working on something else.  See my last post.  I also do not
> implement kernel changes without a consensus from everyone that this is a
> change they'd like to see!  I also don't have the in-depth knowledge of the
> details of the source as you.  Sounds to me like you are just being stubborn
> and refusing to listen to feedback.

 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.

> 
> >  About the complexity, everything new, which application wants to
> > support IN ADDITION, adds complexity. This is unavailable. If, however,
> > the application wants to be an WCOWORK application, there is LESS
> > complexity involved. And many features will become available for the app
> > author at a much lower complexity-level than before. Some features even
> > BECAUSE of WCOWROK mode.
> 
> I agree - but it doesn't have to be a new mode that changes existing 
> calls.  New
> applications can use the new API without fear of conflict with libraries that
> use the old.

 Incredible point of view. I dont see nothing but complete mess here....

> 
> >  For apps that dont know about WCOWORK mode, there is no changes.
> 
> Same as if you use my method, except that you get some extra expandability and
> features from the evnt_multi() replacement, and you can link with code that
> doesn't know about the old calls.

 You need to show me how to do this. I dont understand how this can
work.

> 
> >  For apps that want to be both (that is, run on ALL AES's) there is
> > added complexity, but no more than a new API would create, actually
> > LESS.
> 
> I don't agree.

 Tell me where the added complexity comes from then?

> 
> >  For apps that want to be WCOWORK only, less complexity is involved
> > compared to the FULL area scheme of today. I have to point out again now
> 
> I agree here, completely.
> 
> > that less complexity is not the goal. Its just a side-effect. A lot more
> > functionality is achieved combined with less complexity.
> 
> I agree again.  As I said, I'm not arguing with the benefits of 
> WCOWORK.  No one
> has been.  Its been the implementation as being a 'mode' that no one 
> likes.  We
> all think being WORK-area based is great .. if you would just listen to the
> feedback!

 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.

> 
> >  So, reusing existing API because this is a 'mode' will generate less
> > complexity than implementing additional API's for WCOWORK mode.
> 
> I don't agree.   Might be less work for you maybe because you already created
> WCOWORK.   As I see all the time with every piece of code that someone puts
> into a CVS without prior discussion.  They are always unwilling to rip it out
> because it's their "baby" and they always feel that no one sees the beauty of
> it but them.

 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.

> 
> >  What problems do you have with this?
> 
> Changes existing documented behavior.

 No, it does not change documented behaviour. This is what the 'mode' is
for. Nothing changes until you switch mode, and then new doucmentation
is what goes. But this is history now.

> 
> >  Ok, then I need you to teach me what to do. I dont know.
> 
> Don't change existing calls - allow both.  Well written programs will use the
> new calls exclusively.  If someone links with wout or whatever that knows
> nothing about WCOWORK, it still works!  No problem.

 Well, if you say so. I dont think so. Im really curious as to how you
will do this, tho. One of my goals was to remove this mess, but you want
to keep it by allowing old AND new styles.

> 
> >  gets()? strtok()? Come again?
> 
> An example that really bad functions don't get removed - they get 
> replaced with
> new ones, even calls 100 times more horrible than any AES call.
> 
> >  Hmm.. you mean the AES magically should know what the application
> > wants? A phsycic AES? A medium  AES that goes "hmm... hmmmmmm... I feel
> > this app wants FULL coordinates.. "
> 
> 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.

> 
> The application wants FULL coordinates when you use evnt_multi().  The
> application wants the WORK coordinates when you use the new replacement I
> proposed.   This is much simpler and cleaner than a mode.

 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.

> 
> >  Here it is again. One issue that may work with todays FULL window
> > coordinate orientation, depending on wether the app is correct or not.
> 
> Everyone pretty much agrees that current Windom apps will work just fine with
> dynamic theme changes.  All thats needed is to tell this to the AES.  Add one
> call - make people happy.

 and how many of todays app is linked against windom? This argument is
just....

> 
> > You're right, I dont want to listen to this shit.
> 
> Of course not!   If you added that one call then Windom and many other apps
> would have dynamic theme changes and you've used that as one of your main
> arguments for WCOWORK.  If you implemented that call and then all Windom apps
> could have dynamic theme changes, you'd lose your main argument for Windom and
> all your other arguments would quickly fall apart.  No one would see a reason
> for WCOWORK.

 Therefore I give up. People dont want changes like this. You have loads
of ideas which I think you should try to implement. I'm out.

> 
> >> Tell me what is wrong with that other than you don't like Windom or
> >> anyone elses
> >> way of doing things?
> >
> >  No comments.
> 
> Of course not!  The truth hurts.

 Just to let everyone know, I dont dislike WinDom. I never said I did.

> 
> >  I have, and I fail to see any sense. Perhaps I'm stupid.
> 
> Or stubborn, and unwilling to see another point of view.

 I'm willing to see another point of view. But here I cannot agree with
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.

> 
> >  A pointer is fine? Even dynamically loaded libs have context they have
> > to consider. I always though these libs ran in the context of the user,
> > in user-space, of the lib, and if so, pointers are NOT fine. Have I
> > missed something here?
> 
> What are you talking about?   Of course dynamic libs and plugins can exchange
> pointers with the application they were loaded into.  Otherwise a dynamic
> loaded libc wouldn't function at all - you pass pointers all the time.  I'm
> talking about making all this as one program ... not trying to glue seperate
> programs into one window.   As one program composed of dynamically loaded
> components, you have a single event loop, fewer context switches, ability to
> share memory ... all the things that people love GEM for.   I'm not talking
> about seperate applications - if you have to modify the application for your
> method to work anyway, then just make it a component/lib and not a process.
> See my previous post on how this works.

 IPW discussion is pointless now. We never got past WCOWORK.



 Odd Skancke