Re: GNOME messaging

[Michael Forrest <mef ezlink com>]

Elliot Lee wrote:
> 
> On Fri, 23 Oct 1998, Michael Forrest wrote:
> > I'm hoping to possibly combine the more tightly coupled direct interface
> > mechnism (that you seem to favour) to invoke operations on the
> > gnome-terminal, but am still leaning towards the event system ideas
> > for distributing command line state changes (eg. current working
> > directory). It does seem like an appropriate way of doing it.
> 
> The solution I would use to accomplish the same end result is to have an
> alias called 'vcd' that looks like:
>         alias vcd='cd "`mc --output-final-cwd`"'

Cool. Just to backtrack a little more (!!), one of my other hopes was to
somehow avoid having to fork/exec just to invoke something in the GUI
realm. As I have also pointed out, this is currently one of the
disadvantages of CDE when attempting to interact from a command line
shell.

I have tried my hand at a simple visual shell built using the above
aliasing idea and others (see footnote). What I discovered, though,
is that I was writing _yet_another_ file browser, and it didn't scale
well to a multiple GUI tool scenario.

What do I mean? Let me explain.

My vision was/is to have a shell which can be clustered with a file
browser instance (probably a gmc window), AND other tools like, for
example, a GUI editor like gvim, so that a cd command typed in the shell
will automatically be reflected in ALL these _presently_running_ tools.
Similarly, if you change dir in the gmc window, a cd directive would be
given to the shell (or surrounding terminal?), AND anything else
participating in the cluster. Perhaps this makes the need for
broadcasting a little clearer? To me it means more than a client
invoking an operation on a particular server.

I am aware that some GUI systems try to avoid the whole current working
directory concept completely. For example, Acorn's RiscOs applications
methodology included explicit directives not to rely on it at all. And,
as Elliot points out:

> We could also allow dropping files or directories from an already-shown
> pane into a gnome-terminal.

This allows a little more interaction between tools (yay!), and doesn't
require any notion of clustering.

What I would really like to head for, though, is an environement that
permits fluid (HP/corporate terminology: seamless ;-) and efficient
movement throughout the user interface, _regardless_ of whether its a
shell or native GNOME tool, or even some other GUI tool that has not
even seen the GNOME libs.

Of course, one starts to tread into focus management territory, and that
huge debate over tool invocation policy. For these things I have seen
enough to know that there is no single "correct" solution. However,
providing people with a rich enough environment so that they can create
the solution that fits _them_, this I am all in favour of. So if someone
wants to write a small shell function/alias that transfers window focus
to a "nearby" web browser in order to surf a URL that they just put into
the X selection by grepping a file (phew!), they have the facilities to
do it in a reasonably efficient way. In the cluster example above,
a running gvim editor (which is currently non-GNOME) could be given
the output of a shell pipeline to pretty it up for emailing, perhaps
via balsa.

These last two paragraphs illustrate are why I concluded my initial
proposal with a message translation facility (e.g. GNOME messages -> X
events). GNOME has no official window manager, and not every X
application you run will be GNOME-ified, or even open-sourced. While
not very elegant, this is the type of glue that could make the GNOME
desktop appealing in ways that none of us have thought of.

A good component model makes possible this _kind_ of integration.

Regards,

Michael
-- 
Michael Forrest
mef@ozemail.com.au

P.S.:
I have implemented a very simplistic Tcl/Tk tool (more than a year ago
now, way before I knew about GNOME) that buries an xterm OR rxvt into a
Tcl browser, and works with any of bash, ksh or zsh. The Tcl process
monitors its stdin waiting for notification of directory changes. You
can double click on directories, and the tcl script sends a cd command
to change to that dir. The shell has a number of functions/aliases
defined (with subtle variances depending on the shell) to supply this
info to the Tcl script.

So you get an "explorer" like model, except with a terminal emulator:

+-==-------------------------------+
| dir        |xterm (reparented)   |
| browser    |                     |
| (tree)     |                     |
|            |                     |
|            |                     |
|            |                     |
|            +---------------------+
+------------|CWD widget           |
|            +---------------------+
| dir	     | file browser        |
| stack      |                     |
| browser    |                     |
| (bash &    |                     |
| zsh only)  |                     |
+------------+---------------------+

Clicking on file entries puts them into X selection so that they can
be pasted into xterm. Double clicking was going to open files
(somehow!), but this was not implemented.

The dir browser tree only had the parent, siblings and children of the
current directory, the idea being to provide local navigation. The
stack could provide (potentially) bigger jumps to other parts of the
file system.

An implementation drawback is that this reparenting & sending 'cd'
strings to the xterm requires the TkSteal package's "xaccess" command.
Not part of standard tcl/tk, and unclear licensing situation.