GNOME Command Interface

Synopsis

GNOME Command Interface, or GCI, is an experimental command-line framework for the GNOME Desktop. It is more than a drop-in replacement for GNOME Terminal + bash. GCI is a programming language for interacting with all elements of the modern desktop environment in a clear, discoverable manner.

GCI is a work-in-progress by Daniel Ramage. Support was provided by a 2005 Google Summer of Code grant. Mentorship thanks to Seth Nickel and Owen Taylor.

This document provides an overview of what GCI is and how to get it. This document does not address the implications of some ideas presented here, nor does it get into much technical detail. GCI is a work in progress, so if you'd like to learn more or get involved, you can contact me.

[Bored? Skip straight to the demo movie.]

GCI presenting completions for 'cd'.

Motivation

The Unix command line needs a major overhaul. It is a powerful tool for those who know it, but completely opaque to those who don't. And it has fallen behind the major thrust of modern Unix development - the desktop - because its basic interaction with the rest of the system hasn't changed in 30 years.

A user sitting at a terminal should be able to interact with more than just processes. He should, for instance, be able to tell Evolution to send an email message or be able to query the artist from an mp3 file. He should be able to do these things without having to google or read a man page.

A user sitting at a terminal should have immediate, interactive feedback on the validity of the command line as she types. She should not have to hit "enter" just to sift through error output from an invalid command invocation. Instead, the interface should visually mark that she hasn't specified a valid destination for mv or a valid switch for ls, etc. Think eclipse for the command-line.

Validity cues (red-squiggles) for an unknown directory.

Architecture

GCI is the union of four ideas:

The unification of terminal and shell
A flexible command language for interaction with just about anything
A set of default schemas that plug into the GCI command language
Semantic grammars for each command provided by a schema

For the sake of brevity, I won't go into implementation detail. Below is a brief, bulleted look at the implications of these design decisions.

Now would be a good time to take a look at the GCI flash demo to see the current version of GCI in action.

1. Unification of terminal and shell

Each forked process's output goes into just another region of the GCI back buffer .. so job backgrounding and other sorts of archaic job control are unnecessary.
The GCI GUI knows about all running commands and can propogate information about them into fun helper widgets showing, e.g. whether or not a job is completed, spitting output, etc.
stderr output can be displayed in a different color or region than stdout output

2. Flexible command language

The GCI command language is a language at the intersection of Python, sh, and AppleScript. One basic form of statement in the language is an invocation - this is all that is currently implemented. Take a look at this doc on the GCI control language for more thoughts on the way this grammar might eventually look.

3. Default schemas

Each command invocation in GCI is a method call on an Invokable object. The list of invokable objects depends on which schemas are currently loaded. By default, GCI comes with a several schemas:

'sh' schema that maps all Unix executable names in the path into Invokable objects. The viewer for the returned SHPipe is a standard VT102 terminal (currently buggy).
'app' schema that maps application names into calls over a GCI-specific D-BUS interface. These enable fine-level communication with currently running applications or system services that support the D-BUS interface.
'gci' schema that invokes commands to modify the current terminal.

Another idea is a 'file:' schema that would enable queries or actions to be performed on a particular file based on its mime type.

4. Semantic grammars

Each invokable object can provide a grammar that is used to perform semantic validation on its input. This means that a custom grammar could be provided for 'ls' that would understand all command line switches and arguments for ls, extending the red-squiggle and yellow-squiggle underlines to errors and warnings in the program's arguments. The same is true for apps that wish to publish commands that take pseudo-english, such as app:evolution send email to John with subject "Hello!". The custom GCI chart-parsing engine generates all completion possibilites from the grammar itself. You see this in the flash demo when I get tab-completion options for which commands are exported by 'app:nautilus'.

Check it out

There's more to do in GCI before it becomes a usable replacement for GNOME Terminal + bash with all the promise of a full dynamic language. To see what's been done so far, you'll need Python >= 2.4, GNOME >= 2.10 with PyGTK. Then:

$ cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co gci
$ cd gci
$ python -O src/gci.py

And to start the stub nautilus app listener ... in a new terminal run:

$ python -O apps/nautilus/nautilus-service.py &

Eventually, applications would export their own interfaces over D-BUS.

Next steps

GCI needs a lot more work and input from the community before it can really take off. Here are the main technical challenges in the coming months:

Completions for all types of symbols.
Doc-string propagation into the GUI with completions.
Bug-free VT emulator.
Fleshed out command language and runtime infrastructure (only invocations are implemented).
Viewers for more than just SHPipes (the VT emulator); e.g. live-updating, drag-and-drop-enabled, icon-aware viewers for directories and files.
Filtering via '|' symbol
A major implementation for some application of the GCI D-BUS interface.

I'd love to hear your feedback. Contact me as dramage at this domain.