[MiNT] WCOWORK vs WINDOM for components

[evan@coolrunningconcepts.com]

Quoting Odd Skancke <ozk@atari.org>:
>  I'm not even saying that all the fancy stuff being talked about here
> will ever see the light on our platform, but one thing is for sure,
> WCOWORK makes it much, much easier to have things like that implemented
> later, when more apps use WCOWORK. This is called looking forward :-)

Look further forward!  I've suggested how to handle WCOWORK with new, more
powerful and flexible event system.  The only thing I want to see from a
component system, plugin system, or dynamic library system is the ability for
MiNT itself to load plugins and export a hierarchal tree (maybe a filesystem)
of available plugins (dynamically loaded by the kernel and MP safe, not user).
For  the equivalent of dynamically linked libs, I like Howard Chu's suggestion
of relinkable static libs - should be nice and fast for gemlib, mintlib,
windom, and things of that sort.

>  I would love to hear the theory behind your ideas, tho. Could you
> enlighen us?

Feel free to skip this section and scroll past it as its long and just 
my ideas.
 Its my personal vision on the abtractions I'd like to see, and how both the
features and abstractions of WCOWORK and the features of Windom can be merged
into the component/plugin system I'm working on.  We need both!

This question wasn't addressed to me, but I'll give my theory anyway.  
You want
applications to support a relatively large number of new features.  In 
addition
to WCOWORK, you have new messages to make this work, some way of telling the
application not to open new windows, new API for telling it data has changed,
and a new API to share the data.

For much less work, we can look at what we actually need to implement.  
We want
a way for an application to use external code, and that code needs to write to
another part of a window - you use subwindows and extensive set of new APIs.
Look at how Windom is designed, which is very similar to other libraries
available on other systems.  Windom gets a key down event for a window and
calls the callback for that window.  When a redraw is needed, the callback is
sent.  Windom takes care of telling the callback function where to draw
(normally the working area of the window).

Now - if you want QED and HW in the same window, if these were written to be
components, then whatever is managing those components (similar to windom, and
possibly a new release of windom) would send the calculated areas that these
components inhabit - what would be the subwindow area in your scheme.  All the
callbacks are already in-place!   All you need to do is separate the code
written by the application developer from Windom and make it a dynamically
loaded library or plugin.

Take that one step further and implement a separation between the display and
editing of the data, and the storage of the data, and let both these
hypothetical QED and HW plugins both be data "views" for the same data 
"store".
 You could even go so far as to allow HW to have an edit mode, so that you can
position images and DIVs with the mouse, which changed the data "store" which
would reflect in the QED "view" as well!   Suppose you want to break 
this split
view into two separate windows that can be overlapped?  This would be a great
user interface feature, and since the data "view" plugins know nothing about
the actual window - they just recieve callbacks(methods), they can display in
any window we want in any layout.

With data "views" exporting a set of type that they can handle (based on MIME
types), then the user can choose from a set of plugins to view any data type,
much like the desktop allows different views of a file window.  If you read my
idea for an RPM interface, you'd know the plan is to re-use desktop "view"
plugins with data "store" plugins that get their data by running queries on an
RPM database.  Want to be silly and see the message list of your inbox 
as icons
instead of a list of messages?  Go ahead and change it!

What I'm working on is a method where these "plugins" follow a simple object
system and the "callbacks" are found via a simple polymophic method passing
interface that is way more flexible than what is available in windom or any
other platform, and quite a bit more efficient.   Actually this is the result
of about 5 years worth of design and fiddling to cover all the details and
various pieces that I want without adding any complexity.

>  Dont look at one thing alone. The thing is that all things are made
> possible AT ONCE by going WCOWORK should be the issue. Look at the big
> picture, where WCOWORK makes each single issues easier, and much more
> importantly ALL issues possible, and throw this "This issue could be
> made to work without WCOWORK mode" mentality out the door. Dont get hung
> up on what could work with todays implementation and try to look
> ahead :-)

Again, making the window system WORK area oriented is a good thing.  I just
don't like the implementation.  Lets work together!

I'm wondering if the Windom developers would be okay with a new set of calls
that would implement WCOWORK so that there would be no "modes", AES messages
would be same (just preadjusted to the WORK area when you use the new calls)
and external libraries would be free to use like wind_create safely without
having to know the MODE.  Basically the suggestion I had before which is
actually quite similar to the API that Windom presents to the user now with a
couple of additions, and so I think Windom would gladly support a "Windom for
XaAES" or detect that it exists and use it if the compatibility were there.

Ozk, you want people to use WCOWORK as much as possible, but your own
unwillingness to compromise seems to be turning away half of the 
developers.  I
think some small compromises on both parts could actually get people 
using this
thing and it would be a community developed feature instead of 1 man's vision.

Work together and the benefits of WCOWORK will happen.  Continuing to believe
that your way is the only way will only lead to failure.

>  No, you do not ask HW to draw in a part of a window. My idea is that HW
> uses a pre-created window which is (perhaps) already opened. Thats it.
> The only thing HW cannot do to this window is to create/open/close it.
> When HW deletes the window, the ownership of the subwindow goes back to
> the owner of the parent window. Apart from this, HW sees the window as
> it would any other window.

But the redraws of many applications already have a function that can 
draw in a
part of a window.  No changes needed.   Your subwindow idea requires more
changes.  The application can open a window, and put components into it and
these can get the same sort of callbacks already in use by applications 
without
the complexity of subwindows.

>  And yes, memory protection and related things GOT TO be at number 1 on
> the priority list when implementing new schemes like this. Lets keep
> things simple, clean and understandable.

YES!  Please!  Plugins for components, not seperate applications with no data
sharing!


>  Since the applications should have as little to do with the
> housekeeping (such as sending WM_REDRAWS, WM_MOVED, etc) of subwindows,
> the AES should do this automatically. And since this is a OS context
> job, only the AES can do it. Furthermore, user moves a window (lets say
> a window where qed has lower-part bound to HW), the AES sends WM_MOVED
> to qed (the parent window). Qed then does a wind_set(handle,
> WF_CURRXYWH, ..) which will now generate a WM_MOVED for the subwindow

Uhmm .. this sounds like a whole lot MORE complexity for the AES, more 
messages
passed around, and the possibility of a race condition, since Qed just did a
wind_set() and who knows when HW gets the next message.  At least send the
messages in parallel!

> and sent to HW. The subwindow will not change size, but is clipped
> agains the parent window with  regards to its rectangle list as seen by
> HW, until HW performs a wind_set(handle, WF_CURRXYWH, ..). This is
> housekeeping the AES must do. We could take this one step further by

Sounds like there could be display problems if messages are not sent as 
quickly
as you expect.   It feels like there are race conditions.

> making the subwindow a complete slave of the parent window in which case
> the AES resizes the subwin immediately and implement new _informative
> only_ messages like WM_HASMOVED, WM_HASRESIZED, WM_HASREPOSED, etc. Much
> like the WM_ONTOP and WM_TOPPED messages. One is user action, the other
> is informative, that is, your window got topped because another window
> was bottomed.

New messages?   Do't we enough of these to worry about?

>  Ah, ok. I dont know html at all :)

Read the DOM.   An HTML document is actually an object tree.  It will 
be awhile
before I get around to implementing the HTML DOM within the framework I want.

>  yes, subwindows have their own window handles, ofcourse. Slider,
> widgets, etc. etc. is pre-set by the subwindow creator. So, if the
> creator creates a window wthout sliders, no sliders will be available.
> Toolbars will be there as it would be in any other windows created by
> the app useing the subwindow. And we could have an element in the
> iws_register structure holding the window widgets (sliders, etc) which
> this server wishes to have on its subwindows.

Gets more complex by the minute!

>  Please let us know the theory behind your ideas. I very much would love
> to hear it :-)

Yeah, I'd like to see what Oliver has in mind as well.

>  Ah, let me promise you that I know exactly what you are talking about
> here! I was badmouthed because I just went ahead and implemented WCOWORK
> (well, as of yet it is more experimental than an established solution)
> so be careful ,-)

The problem wasn't that you did the tests and developement work, the 
problem was
 that it made it into the public CVS without commentary or consensus.  I think
people prefer experimental stuff in your own tree, not the global one.

-- Evan