Baboon Components

[John R Sheets <dusk smsi-roman com>]

(Was Re: getting started)

Martin Pool wrote:
> 
> Again, it seems like this is in large part an education problem: you
> have to make it seem obvious that when people write their
> MrWonderPaint app they export useful interfaces, rather than just
> writing calls within the app itself.

As I understand it (Baboon and COM), this will be handled by the
creation of standard IDL interfaces to standard components. 
Thus, if you want your painting component/plug-in to support both
image editing and text creation (for the image), you would
implement both the PaintTool interface and the TextTool interface
for Baboon (I'm making up the interface names for demonstration
purposes, BTW).  

The Baboon docs should contain a master list of all standard,
official interfaces so that we won't have a splintering of
interface API's.

The beauty of the approach is that the GIMP PaintTool interface
would be exported from an existing full-fledged application,
while the MrWonderPaint PaintTool interface could be a simple
non-app object accessible only through CORBA.  But the word
processor wouldn't know the difference.  It would just
communicate polymorphically to whichever Baboon object it had the
reference to.
 
> Perhaps if the framework included an abstract class for document-based
> apps then authors could fill-in-the-blanks for OpenDocument(),
> GetView(), PrintDocument() and so on, get more of the app done
> automatically, and get CORBA interfaces to those functions for free.
> Just an idea.

Yeah, this is pretty much what VC++ does.  I think we should
definitely keep it in mind when we start developing our document
model.  I think they (i.e. MFC) do a good job of handling
printing.  Most of the tedious repetitive stuff is done behind
the scenes.  The critical step, the actual drawing of the printed
page (e.g. OnPrint()) is exposed, as are the setup and cleanup
steps.  Naturally this works better with C++ because it's easy to
override functions.  You'd probably have to set up signal
callbacks to do something similar (and multi-lingual) in GNOME. 
Any other thoughts?

One lesson we should pay mind to with VC++ is the whole
Document/View model.  Ecccch!!  The general idea is good:
separating your data from your GUI.  However, it's very poorly
implemented...very non-reusable.  Your GUI class (view) and data
class (document) are immutably tied together at a class API
level.  The view calls the document by name.  You can't pick up
the view code from one app and drop it into a different (no
matter how similar) app.  Not without extensive rewrites,
search-replace, etc.  I've heard the MVC model
(Model-View-Controller) that came out of Xerox Parc is much
better, but I don't know much about it.  Worth looking at, too.

I imagine Baboon will solve this problem by abstracting the
data/GUI distinction through CORBA.  Your View will be an
externally-implemented object; your data will of course be local
to the app.

This brings me to a question.  Will Baboon/CORBA be capable of
encapsulating widgets as well as data services?  Will I be able
to build, for example, a checkbook register component, complete
with GtkCList (or GnomeCanvas, whatever) that I can just drop
into any application by invoking & initializing it?  And how
seamless can I make it with my own application?  Would it have to
run in its own window, or could I bind it to a child window
inside my app?

Okay, more than one question.  (c:

> Having used VC++ a little it seems important to have an API that
> humans can deal with without needing wizards to generate the code for
> them.  

Yes, and I find it very funny that Microsoft keeps shooting off
fireworks about how powerful their wizards have become (a major
marketing point for VC++ 6.0), when the real problem is the
exaggerated complexity of their implementation.  Kind of like
having to invent a huge half-ton new-age sewing machine to handle
a special proprietary two-pronged sewing needle.  

John