Re: [MiNT] WCOWORK implementation : conclusions.

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

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

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.

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

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

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

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

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

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

>  What problems do you have with this?

Changes existing documented behavior.

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

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

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.

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

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

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

>  I have, and I fail to see any sense. Perhaps I'm stupid.

Or stubborn, and unwilling to see another point of view.

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

> > However, you can also get a pointer safely with your crazy method of gluing
> > applications together using the /SHM.   Don't assume I don't know about
> > virtual
> > memory and memory protection.   Methods that abuse the single 
> > address space of
> > MiNT don't even come to mind for me since I've been on Linux for the past 12
> > years.
>
>  Well, with the idea I have, this added complexity is avoided. Now go
> back and read your own comments about added complexity.

No - My method doesn't need /SHM.  Yours will since if you want to share data
between QED and HW as separate processes then you will need some form of IPC,
and if you are sharing a whole HTML file and want immediate updates to 
changes,
then you either pipe things like mad, slam the disk constantly, or use shared
memory via /SHM.   I think your only hope to make your idea work is /SHM.  In
mine, its all in one address space, and one method call gives you a pointer to
the data that is shared between each.  However, I wouldn't be sharing the text
version, but rather an object tree formed by parsing the html.  As a tag is
completed in QED, the object is added to the tree and shows up in HW through
object change notification.

>  Ok, here I really feel like I'm missing something. How do two processes
> share data cleanly without using some form of IPC? Please I want to
> know.

As I said - you will need IPC because you use processes.   This is the wrong
approach to take for what you are attempting.  What you want is a clean
component system.

>  This is a client/server'ish sceme. you do the rest of the math. And no,
> this really isnt a very compilcated thing. Its just a new thing. And new
> things like this needs new ways of thinking. See below for a fantastic
> explanation about the menubar.

I understand what you want.  Its not that new, just a bad implementation.

>  client/server scheme. Ofcourse the client's, the owner of the parent
> window, menu-bar is ontop, since the app bound to a subwindow is
> providing a service, i.e., it can be regarded as a server. I thought
> this was obvious.

So if HW is the subwindow of QED, the QED menu bar shows and you don't get the
HW menubar?  Wonderful!   Seriously, I hate that idea.  We'll have to 
all start
using pop-up menus for everything becuase your system won't give us a 
menubar if
you are in a subwindow - yet more things that the application must be 
changed to
consider, making it so much easier to just change the app to a 
component.  Then
you have a data/view seperation within one process and not a client/server
seperation in multiple processes.

>  Are we confusing the idea I have that WCOWORK makes possible with
> WCOWORK itself? Inplace Windowing IS NOT WCOWORK mode. It is a new thing
> that WCOWORK makes possible.

Makes it possible with a huge number of other changes to the application.  And
I'm not convinced that WCOWORK is really whats making it possible.  Its 
all the
other changes like not opening windows and such!

Obviously the new wind_getx calculations would be perfectly fine to use with
"subwindows".  The FULL and WORK area are the same for a subwindow, so 
it works
just fine!   WCOWORK mode isn't required at all!  If you use 
wind_calc() instead
... lets see .. no widgets, not even a title-bar, so wind_calc() would likely
give you a slightly smaller WORK area than it should, so you'd have a slight
border of a couple of pixels around the subwindow that would get wasted.

>  Would it be silly to use temp files for this, you think? Ok. You're
> entitled to this opinion. When did I say that new messages was not

Yes!  Don't thrash my disk to move data around.  Even a pipe is faster than
hitting the disk.   Why would you choose the slowest method of moving data
between processes?  /SHM is the fastest - no copying.

> necessary for IPW (InPlace Windowing) to be usable? What I said is that
> the windowing functions of a WCOWORK application needs next to no
> changes when working with subwindows vs. its own windows. I also said

It looks like quite a few changes!

>  You tell me I dont read what you said. Now I can tell you that you dont
> read what I have said. WCOWORK is not IPW. IPW is possible because of
> WCOWORK, if I decide to implement it.

I understand that.  Neither are good implementations.  And all the benefits of
WCOWORK would still be just as effective with the alternative I suggested.

> > And if HW is getting the lower half of the window for its subwindow, 
> > then the
> > toolbar goes in the middle of the window?
>
>  Yes?

Read some of the original design ideas behind GEM.  Quite a bit of 
research went
into doing simple things like memory studies.  The menu bar goes up top 
to take
advantage of muscle memory.  It works almost as good, but not completely, when
the menu bar is in the window since its just in relation to the window and not
the screen and your mental focus is set relative to the window.  Having
toolbars in teh middle of windows is certainly not a good user interface.

> > This sounds like a nightmare since the application has to be 
> > changed, and the
> > user interface sounds like a horrible hack.  I don't like this idea at all.
>
>  Thats because you dont understand the idea. This reveals that you have
> been talking about a thing you just didnt get ;-)

Just because I don't like it, doesn't mean I don't understand it.  That is so
typical to say that I don't understand just because you somehow feel you are
smarter than me because anyone that doesn't think your ideas are 
wonderful must
be stupid!

>  Ohmygod. Cannot run in separate processes? What are you talking about?

Running things in seperate processes is requiring a huge amount of messages
between processes (slower), and data sharing, which you evidently want to do
with temp files.  If you don't see how that can be slower than a component
plugin system, then you are mad.  The more IPC you have, the more task
switches, and the slower it gets .. and disk IO ... do I have to tell you?


>  Ok, you obviously do not know what you talk about, and I'm really
> looking forward to your "working alternative" solution.

You never read it obviously.