Re: [MiNT] WCOWORK vs WINDOM for components

[Odd Skancke <ozk@atari.org>]

fre, 22,.07.2005 kl. 14.33 -0600, skrev 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.

 Most of the things above does not belong in the AES kernel at all.

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

 I mention WCOWORK mode and what benefits it may have in the future, and
all of the sudden there are so many balls in the air that one cant
breathe. I read what your plans are, but I have no idea how you want to
implement things at all. You seem to mix lib functionality with what
should be in the AES kernel. All this talk makes me feel unadeqate, I
dont understand half of it (apparently noone else either since noone
else uses these ideas). I therefore kindly ask you to take over XaAES
development, I've had enough.



 Odd Skancke