Meta-Application Interface: a proposal

David Orme david at
Sat Jun 19 09:50:24 EDT 1999

Ferdinando Villa wrote:

> <<SNIP>>
>         This leads easily to the idea of a 'meta-application
> interface' as a core desktop functionality, where users can 'patch'
> applications together graphically (connecting their icons with the
> mouse), save their meta-application to the desktop, and use it as a
> single app. At the very simplest level this allows to use the UNIX
> pipe mechanism graphically: e.g. to print text files as postscript, I
> create a new meta-app (a box with input and optionally output ports),
> drop the ascii-to-ps translator and the ps-printer icons into it,
> connect the meta-app input to the translator and the translator to the
> printer, assign an icon and save it. Now I can drop my ascii file on
> the icon and have it translated and printed in one step. It's not much
> of a deal but you get the idea - try and find something like that on
> Windows or MacOS. One of the most powerful features of Unix comes to
> the friendly desktop. Myself, I would love to have it.
>         Going up with the complexity, you can carry this to a very high
> and very new level of power. As a first stab at it: through an API,
> applications can notify their 'output ports' and make them available
> as outputs in a meta-application context. This translates in users
> being able to select graphically the ports from the application's icon
> in the meta-application editor. The 'semantics' of the info that
> passes through there can be described in XML and the connections, of
> course, can be based on CORBA, which makes it possible to use remote
> apps ('services') as well. An application in the meta-application can
> play a 'lead role' by showing its own interface when running the
> meta-app, and is notified of the connected apps through the API,
> adjusting its menus and functions (possibly directed from similar info
> set in the connected apps) according to what services are available to
> it in the meta-application context. Specific 'GUI' apps can offer
> specific services like e.g. interactive output port selection: you
> drop the Ascii file on the meta-printing app and you get the pop-up
> asking which printer/viewer you want it to print on (all printers are
> connected to the outputs of the switcher).

This is a good idea.  It overlaps somewhat with existing work, although I am not
aware of existing work that uses XML as the data modelling language.  The Bonobo
component architecture will let you hook software components together using
CORBA--the components are able to read or write using a specified
CORBA interface, and you can hook up compatible components in a pipelike way.

Another PhD project I'm aware of that was similar to this was Cube, done at Univ.
of Illinois.  It is much lower level than what you are trying to do but many of
the concepts are similar and the bibliography should be useful to you.  Here's
the URL for the project:

Also, the Gnome-filer project (soon to be renamed) aims to provide a programming
language-neutral IDE, specifically designed to let graphical languages like what
you describe "plug in".  Basically, our idea is to provide a graphical project
and build manager plus a pluggable API for developing graphical editors for parts
of programs.  These editors won't be limited to just editing data entry forms,
but could graphically edit an object specification, database schema, or maybe
graphically "glue" components together using pipes or any other relevant
abstraction to edit applications.  It sounds like your idea might plug nicely
into our framework.  Also, for text editing, Gnome-filer will use the
Gnome::Editor Bonobo interface so when Emacs, Vim, Joe, etc., are upgraded to
support this interface, you will be able to work comfortably in your favorite
editor *and* have graphical app editing tools available to you.

I'm the maintainer of the Gnome-filer project and if you're interested in working
with us, let me know.  Currently there is no project home page (until we get
ready for an initial developer's release), but our source code is stored in the
Gnome-filer module in the Gnome CVS repository.  For more information about how
things work, our goals, etc., consult the TODO file in the repository and maybe
compile the current code.  (The current code compiles against the Gnome libs
included in Red Hat 6.)

>         In any case, thanks for reading, and best to you all

Wish you the best!


Dave Orme

David Orme                                       LINUX...
david at already goes there               :-)

----- End of forwarded message from David Orme -----


More information about the Pipet-Devel mailing list