Re: [MiNT] WCOWORK implementation : conclusions.

[evan@coolrunningconcepts.com]

Quoting Odd Skancke <ozk@atari.org>:

>  What other ways would be better than WCOWORK, then? WCOWORK is a very
> simple thing, it is about having the windowing work with WORK area of
> windows instead of the FULL extent. That it. Apps can set the FULL area
> of windows, and this is done like so; App knows the area onscreen it
> wants to cover with a window - convert that to the corresponding WORK
> area (wind_get(handle, WF_CALCF2w,...)) then wind_set(handle,
> WF_CURRXYWH, ...). I've said this a million times now, what is the
> problem?

I know how this works.  You don't have to repeat it.  But I still think this
method is not as good.  Make a new more-powerful API with more features and
better flexibility, and this API should be WORK area based instead of FULL.

>  wind_calc() cannot be used here, because now you have two different
> window types and wind_calc() is contextless. No way for the AES to know
> which window type you mean. This is why I want wind_calc() depreciated.

Fine, my mistake.  wind_xget() then.

>  No. Either the application is a WCOWORK client or it is not. Lets keep
> things simple and clean. I'm not even gonna open for possible havoc like
> this by allowing the app to use one and the other. Only one or the other
> is acceptible.

I don't believe that changing how API calls works is very clean at all!
Nor do I think that making it impossible to link libs that know about the new
mode is a good idea when another working alternative is available.   The real
problem though is your absolute unwillingness to consider anything other than
your own method.   Anytime someone has a problem with your ideas, you shoot it
down without listening at all.  Unacceptable?   Please back that up with some
logic as to why this is unacceptable.


> > I understand your concern.  But I think if you look into it, the problems of
> > mixing the two can be solved easily, especially if you use the API I 
> > outlined
> > which completely seperates the two APIs.
>
>  This would completely work agains having WCOWORK in the first place.

Why and how?  Empty statement without reaseons to back it up!

>  Yes, I'd like to hear your issues. But keep in mind that I want WCOWORK
> ONLY and not keep the old way by making it available when WCOWORK is
> enabled by the application. This is vital, and the only sensible thing
> to do. If not, apps cannot benefit WCOWORK, because the AES has to take
> into account that they MAY use the old-style even now. This would
> encourage continuous use of the old-way, which definately is not a goal.
> This adds complexity to both the AES and the application. So, no way I'm
> gonna be talked into mixing ;-)

Actually, there isn't any real work involved when the application MAY use the
"OLD WAY", as the AES already has to do this anyway to support old
applications.  In fact, your way is more complex because the behavior of AES
calls changed depending on some flag or mode.  This is where the complexity
comes from.  In a clean design the behavior of these calls should not change.
Then there is no extra work for the AES to do.

It doesn't encourage use of the old calls at all.  Thats what documentation is
for, and providing an API that is WORTH people using it.   Don't force people
to use some new flag that suddenly removes capabilities that you don't like -
give them a replacement that is worth using!

I don't see you removing gets() and strtok() and all the other really HORRIBLE
calls from C libraries that lead to bad behavior, crashes, buffer 
overflows and
security leaks.  Allowing a 3rd party library to open its own window without
knowing if its WCOWORK work or not and having it actually work as expected,
isn't as bad at all.  In fact, I don't see a reason not to.

>  Again, this is not true. It would work as long as apps dont store
> values. Problem is, they do store values. If keeping the FULL oriented
> way of today and theme changes was the only goal, it would be enough for
> clean apps (not storing values). But how does the AES know?

You see I can tell you aren't listening to me.  You didn't read what I 
said.  I
said to have a new call that tells the AES you can handle dynamic theme
changes, and keep it seperate from WCOWORK.  Its already been shown 
that Windom
applications would not have this problem.   If you implemented this call, then
I'm sure windom developers would add it to windom, and with just a quick
recompile you'd have plenty of existing applications TODAY, that will 
work just
fine with dynamic theme changes, safely, without erwriting the application to
use a new mode.

Tell me what is wrong with that other than you don't like Windom or 
anyone elses
way of doing things?

>  I do not agree. In a perfect world it would be possible, but as it is
> now its not possible.

See above, and please read it.

>  First of all, this "pointer to the data being held by Qed" philosophy
> is what keep our system from being workable under MP and gonna make VM
> hard to implement. By these words you just showed me that your ideas
> need to be really examined before evaluated.

Stop - we are talking about completely different things.  In a regular 
component
system, the components are simple libraries, often dynamically loaded.  A
pointer is fine.

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.

>  While you could do so, it would add alot more complexity to existing
> applications than WCOWORK would. I'm also very instersted in knowing how
> you want to share data? Please dont say 'pointers'!

See above.   Get data, not share data.  My way actually uses a simple message
passing system internal to the application.  The data is simply shared.   Your
way requires some IPC scheme of some sort, and since you are working with very
large amounts of data that changes constantly, I would go for /SHM.

> exactly the reason the AES has to deal with it. And what does the menu-
> bar have to do with this? You obviously dont know what you're talking
> about here ;-)

You act like this is a very simple change.  As long as the applications 
support
your precious WCOWORK mode (by which you really mean to say that they use the
working coordinates only and not the FULL, it is not dependant on your
particular implementation that we don't like) then you can do these wonderful
things that emulate a component system.  However, this is wrong.  QED and HW
both have a menubar.   Which menubar is shown?

>  The idea is that a subwindow is, to the application bound to it, just
> another window, and thats final.

And when the window is topped, that applications menubar is shown, but now you
have 2 applications in this window.

>  The owner of the window ontop's menu-bar is shown. The data edited by
> qed is loaded by HW when told so by Qed using AES messages. Ofcourse, a
> set of messages related to 'inplace windowing' would be necessary. This
> way Qed can tell HW whenever it should rerender the data held in a file.

So these sub-windows can be TOPped seperately?  And then the menu bar flickers
back and forth?  How does the user know which subwindow is the top one?  They
are sharing the windframe, yes?  So the windframe wouldn't change.

And now you finally admit that WCOWORK isn't the only change required.  Now
there is a set of new messages for inplace windowing. And you haven't said how
the data is shared as it would be silly to push it all through AES events or
save it to disk constantly.  You'd have a message that the data changed every
keypress.  A real component system wouldn't need messages for this - 
things are
automatically updated on the fly.

>  If HW has a toolbar, that toolbar will show up in the subwindow,
> because, once again, the subwindow is just another window to the
> applications bound to it.

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

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.

>  Be very careful how you design the components system, and how they
> share data. Lets try clean methods for once.

Trust me - everything I do is clean and cross-platform.   You are the 
one trying
to make a new class of applications using a very un-clean design.  The whole
premise behind this subwindow idea is flawed - you've shown that existing
applications cannot be used this way, and if you are going to change the code
to make them work together, then you might as well change the program into a
real component architecture that can deal with things cleanly.  Thats what you
are trying to do, but they cannot run in seperate processes and be efficient,
nor will the user interface be very consistent.

I would much rather see a good multi-line text editor AES object, and a good
auto-updating, printable, Canvas widget for holding VDI displays as I outlined
before.  These are features real applications can use that will help
programmers, and could be added to other systems.

Your premise that we must support your implementation of WCOWORK and throw out
the ability to safely use older API calls with the new in the same 
program (via
linking of existing 3rd party libraries) is based on your desire to make this
new subwindow thing work.   And  1 - you can do it with the mixed API, 2 - the
subwindow idea is not good.  Lets allow the existing libs to work instead of
forcing people to rewrite their apps for this crazy subwindow idea - few apps
will ever take advantage of it.

-- Evan