Re: getting started

[Martin Pool <mbp wistful humbug org au>]

On Wed, Aug 26, 1998 at 09:33:38AM -0500, John R Sheets wrote:

> But yes, it would be a tremendous jump to be able to switch tools
> from within the same app.  Theoretically speaking, let's say I
> use the Gimp tool palette 90% of the time when editing inline
> images in my word processor; however, sometimes I just need that
> extra special airbrush filter that MrWonderfulPaint (or whatever)
> has.  So, I click on the Tools menu, switch image tools, and
> boink! my tool palette has changed from Gimp's to
> MrWonderfulPaint's.  My word processor doesn't care which tool
> set I use.  Purty nifty.  Can't wait.

So it seems like the two important things are to have an
inter-component interface efficient enough to be used to every
display-expose or mouse-click event without losing too much
performance; and to have more or less standard interfaces for
representing images, managing toolbars, drawing onto the screen, and
so on.  Versioning is probably pretty important too.

Somebody mentioned using CORBA instead of shared libraries as a way of
loading new components into programs.  It seems like people are
currently adding excellent new components by the bucketload to the
GNOME source tree to go into libgnomeui.so.  If we're going to use
CORBA instead, then I suppose we have to settle the interfaces and
make it easy for component-users and component-writers to use them;
and then explain to people that they should be creating CORBA objects
rather than adding to libraries.

> Great stuff!  This'll be the building block upon which the
> pluggable tools thing (mentioned above) comes into existance. 
> The more CORBA language bindings we have, the more tools will be
> ported/exported to work with GNOME in this fashion.  

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.

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.

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.  Perhaps GNOME (Baboon?) need to provide wrapper functions
around CORBA, the same way it wraps GTK+ to handle the common case.

Is there a Baboon list?

I'd love to work on this, but can't see where to begin: if somebody
with more of an idea of the bigger picture would like to give me
directions or pointers I'd be indebted.  (Would the CORBA persistence
service be useful, or an interface to wrap widgets?)

-- 
Martin Pool