GNOME messaging

[Michael Forrest <mef ezlink com>]

Hello people,

The following are some ideas that have been kicking around inside
my brain for longer than I care to remember. After following
gnome development for a while, and having adopted it permanently
on my desktop, I think gnome would benefit from a messaging model
on top of CORBA - messaging which can be end-user extensible.

Are these ideas in line with the Baboon architecture?
It seems to me that Baboon is about internals of components.
Is this correct?

I am hoping to be able to contribute some code towards these
ends (putting some of my commercial CORBA skills to a good cause!),
but wanted to know what others thought first.

Regards,

Michael
--
mef@ozemail.com.au

		   GNOME messaging for shells and tools
		   ------------------------------------

The shell command line is the longest standing UNIX user interface. Even
in the midst of Graphical User Interfaces, you can still find command
line shells lurking, existing as they usually do in terminal emulators
that support their continued existence. 

So why are they still there? 

The full answer to this is a complex one, although it usually involves
arguments about speed, flexibility and power. But what about ease of
use, complexity and learning curve considerations? GUIs do a lot helping
these usability issues, and GNOME already has many outstanding examples
that show this. 

So how about a related question, then: Why aren't command lines better
connected to other user interface components, in an attempt to get the
best of both worlds, and to overcome the shortcomings in each? 

This proposal basically suggests using messages to connect command line
shells to other user interface elements such as file browsers, editors,
customizable dialogues, and perhaps even the window manager. 

Obviously, many tools already exist that attempt to bridge this gap
(e.g. Mini Commander, gtkfind), and some may even have command line
interacting elements (e.g. emacsclient, netscape's '-remote' option, and
the text mode midnight commander's subshell). 

A more complete solution could be made possible by using a CORBA based
message/event broadcast system, with an easy injection mechanism for a
shell. By "easy injection" here I mean access, via shell built-in
facilities, into a server that actually creates these CORBA messages on
behalf of the requesting shell. 

A number of other GUIs use some kind of non-window event distribution
mechanism: MacOS has Apple Events, CDE has Sun's ToolTalk, to name just
two. ToolTalk is an interesting example of a user extendable messaging
system built using RPCs. While CORBA fundamentally provides GNOME with
non-window based communications, GNOME really needs a higher level
message system built with CORBA to allow broadcasting of messages whose
type and scope can be easily defined dynamically, possibly even by end
users. 

An extensible broadcast messaging system would make possible a number of
interesting scenarios: 

    - gmc could listen for change directory events from a (particular?)
      shell. If the enclosing gnome-terminal also subscribed to the
      event system, gmc could even send back directory changes as 'cd'
      commands to the shell. This would ease directory navigation, and
      make it possible to automatically show directory contents without
      cluttering the terminal. 

    - Double clicking a file in gmc could send an "open" event, that,
      depending on the file type could also be routed back to the
      command line, or maybe to a currently running GUI tool, in a user
      configurable fashion. 

    - External GUI dialogues would be able configure the shell itself,
      as well as its environment, again using the gnome-terminal to send
      input to the shell. This would be helpful for making obscure shell
      features and environment variables more accessible, especially for
      users who may be less command line literate. For those of us who
      use multiple shells, this could also ease the pain of switching,
      while still allowing shell specific features to be manipulated in
      an appropriate way. 

    - Many of the more complex UNIX commands usually have options which
      are less often used, and therefore easily forgotten. Using
      dialogues to help complete, or even construct, command lines could
      alleviate some of these problems (GUIs being much better at self
      documentation). Since the command would be fed back to the shell
      for execution and to be put into the shell's history, this could
      even be used as a teaching tool by showing command line
      equivalents. Using an interpretive tool here that "knew" the
      options/syntax for a program would be cool. For programs with
      getopt() style argv parsing, this information could be extracted
      straight from the options table of the program itself. 

The first and third points above obviate the need of a message scoping
facility, where particular messages would optionally only be delivered
to a named subset of all the clients in a session. This subset could
possibly be just based on the name of the tty of the shell involved for
the situations described above. At a more general level, this also
provides clustering concept that would be helpful in other situations -
especially where multiple invocations of a tool is involved. If that
tool is composed of sub-components that used the GNOME message system
for end user extensibility, the tool and its sub-components would need
to be in a separate cluster that is distinct for each tool invocation. 

I am sure many other useful scenarios besides the four above could be
put in place, especially with an easily extensible messaging system. If
it were also possible to translate these messages into window system
events in some kind of configurable way, it could possibly allow partial
integration of non GNOME compliant applications and window managers.