Are Unix GUIs all wrong?
Posted 11 Feb 2001 at 16:14 UTC by nelsonrn
Have we gotten the Unix GUI all wrong? Unix is more than anything
else a big bag of tools for people to use to construct a solution.
Argue away that the GUI is part of that solution, and not part of the
toolset. But I think we're selling the gui short.
It seems to me
like we could do a lot more to integrate the gui into standard Unix
tools. For example, if I run tar inside X, then tar ought to pop up a
completion bar. Why not? Or tail --follow name=/var/log/maillog
ought to tell me how many lines per minute it's scrolling past. Why
I wonder what we would have in the way of tools if people said "Okay,
EVERYBODY has a GUI". That is, if there was no console mode per se.
If the first thing that init did was throw you into X instead of the
last thing. What if the shell popped up a window, showing you the
last N commands you typed, or showed you what you would get if you hit
tab at that point. Or let you mix a file selection dialog with the
command line. You could type rm
<special-key-to-popup-file-selection-dialog>, select the files you
want to remove, and when you exited, the output from the file
selection dialog would be inserted into the command line.
What if the Unix GUI didn't need a mouse? What if every application
could be controlled solely with the keyboard? What if every new
window that you popped up got the focus by default (this works with
click-to-focus, but you need window manager help with
What if I could type a key to the shell which took my current line,
handed it off to a gui program, and when it existed, replaced the line
with the contents of the line?
The command line lives in a completely separate world from the gui,
and that's wrong.
Sort of., posted 11 Feb 2001 at 16:46 UTC by egnor »
Some aspects of the command line need to remain on the console, so they
can be piped to other programs. And even if everyone has a GUI, system
processes often have no interface at all. If 'tar' always pops up a
status bar, what happens when 'tar' is running from a cron job? Does
the logged-in user get a random status bar on their screen?
You are also presumably assuming some sort of remote-display system
that's at least as efficient as a remote console. (X is no good; I can
use command-line tools over a 300bps link if that's what I have, but the
X protocol doesn't work well until at least 64k-128k or so, and in many
cases not even then.)
If you solve these problems, what you're left with is the Plan 9 user
interface, give or take. Plan 9 takes the philosophy that consoles are
dumb teletypes (no VT100 emulation); if you want output that can be
redirected, use the console; if you want something like 'curses', that's
what the GUI is for. (And yes, transparent remote access to everything
is possible.) It's not a bad model; the VT100 character-grid interface
really has no reason to exist.
(If you don't solve these problems, but merely brush them under the rug,
what you're left with is the Windows user interface, give or take.)
Is that what you had in mind?
Interesting points; I particularly like the idea of a GUI without a mouse.
One of my past diary entries discussed some aspects of this: WMs should,
by default, give windows visible IDs relative to their virtual desktops
so we can address them by means of keyboard sequences or, eventually,
voice control. But note that windows grabbing the keyboard focus is
dangerous: I wouldn't want part of the password I'm just typing being
entered into the IRC client I just started. But I'm getting too much
into specifics here.
Regarding your main idea: I guess it all boils down to abstracting the
input data, the processes performed on it ("Model"), the information
provided by the data and those processes ("View") and the means of
interacting with them ("Control") in a standard way. This way, the
current "runtime environment", controlled by preference settings, would
be able to provide different means of interaction and visual
representations of data and processes (not in the UNIX process sense)
dependant on metadata describing the "view" information and the
"controls" associated with it. In practice, this would probably be done
by dynamically linking against different libraries depending on your
environment, or something to that extent.
IMHO, This is a good idea, and it should be implemented (this way, I
might even finally start to take GUIs seriously). However, it'll need a
tremendous amount of work to design this thing, and even more work to
actually build it. Unless KDE or GNOME (or something in their order of
magnitude) pick this up, I don't see it happening outside the
But if you've got the time on your hands to work out a full proposal for
this, plus some code to show that it works, you should do just that.
On an initial reading, this does seem like a good idea. However,
there are a lot more issues to think about than you are giving credit
for. The first is pretty obvious, and others have mentioned it: tools
still need to be scriptable, and not require a GUI to run. This is
probably the least problematic concern - if people were to rewrite
pretty much every tool to give them extra GUI functionality, it would be
easy to add in a --nodisplay parameter.
The bigger issue is that of consistency. What programs should display
what? Should things like tar only popup a progress bar? Why not a
filemanager window? Same for other file manipulation utilities. Then,
what about things like grep and diff? What would they do? Should there
be some kind of graphical pipe or redirection? You may be able to come
up with a personal-preference answer to this, but that doesn't mean that
the work is done. It would have to be something that is as intuitively
obvious as possible, and consistent behavior across all tools. This is
a pretty huge challenge. So while things like MVC make it much more
technically feasible to solve the problem at hand, a technical solution
is near useless if the GUI isn't worthwhile.
Perhaps a more interesting exercise would be to consider the retooling
of metadata on UNIX systems. Hierarchical filesystems can be somewhat
nice, but they are a pain when one file could fit in multiple places.
Why couldn't we store files with keywords attached to them? And keyword
queries would take us to virtual folders with the search results? I
think that this would be a huge foundational step forward - something
all apps would benefit from, whether on CLI or GUI.
jameson, let me humbly direct your
attention to the berlin project. MVC is one
corner stones. I think that composition as the universal mantra in the
unix world is a powerful concept, and that we indeed didn't manage to
blend the compositional nature of UI design with the traditional unix'
way of life.
But I also agree with Jef Raskin about the need to hide that
compositional complexity, if possible, from the user. After all, it is
nice to be able to compose and configure your own interface, but you
don't want to be concerned about that all day. Let the user focus on the
content, instead of distracting his attention by all the possible
and adaptations he could apply. 'Keep it simple, stupid !'.
Some programs, posted 11 Feb 2001 at 21:51 UTC by nether »
This is not an entirely new idea. For example, there's Ion, a window manager
that's designed to be used with a keyboard. (Yes, you can use
it with a mouse, too, but it's not quite what you're used to.) I use it
all the time.
Ion doesn't provide much in the way of integrating command-line tools
with a GUI (try XMLterm for that), but
it's definitely a step towards closing the gap between "console" and "GUI".
The mention of XMLTerm reminded me about the EFM approach to integrating
the command line with the GUI. EFM had a graphical file listing, but
you could also just start typing in commands. It worked pretty well.
My understanding is that Nautilus may incorporate this feature post-1.0.
That would probably be rather useful. It doesn't solve the issue of
having commandline tools pop up GUI windows and such, but it does manage
to avoid it. Nautilus is setting out to create GUI tools to eliminate
the need for CLI. As much as I'd like to think otherwise, I still can't
use linux without a console. I don't even notice it - but a novice user
most definitely would. What we should try and focus on is incorporating
(or even surpassing) the expressiveness of the command line into the
simpler interface of the GUI. Pointing, clicking and dragging has
basically no semantic value right now. I have high hopes for what
things like "emblems" in Nautilus could do - little symbols that you can
attach to an icon that represent an action. If you think about it, that
has a lot of power if it is implemented well. That should be
complemented by the ability to use things like Nautilus or EFM like
"graphical shells" - not filemanagers per se, but just a graphical
context for inputting commands. Of course, as I said in my last post,
such things would benefit even more by a semantically richer filesystem
and increased metadata. But that requires a pretty big change.
That a Unix system is totally usable on a terminal is an advantage.
Any attempt to add GUI to command line tools must ensure the GUIs are
Another thing to ask is that, is it justified from a
usability/productivity point of view to add GUIs to command line tools?
The fact that a typical Unix desktop has more xterm windows more than
anything else supports the usability of the current GUIless model for
the command line.
> What if the Unix GUI didn't need a mouse? What if every application
could be controlled solely with the keyboard?
This is already possible in KDE 2 for a long time via DCOP.
Fire up kwrite (make sure you don't have two kwrites there at the same
time -- otherwise you have to add the pid to those commands) and type
into your favourite xterm:
dcop kwrite KWriteIface insertText 'Windows rocks!' true
dcop kwrite KWriteIface setCursorPosition 0 8 true
dcop kwrite KWriteIface insertText 'sux! KDE ' true
dcop kwrite KWriteIface shiftHome
dcop kwrite KWriteIface writeFile 'conquer_your_desktop.txt'
or check your Mail using KMail by entering:
dcop kmail KMailIface checkMail
or bind the command "dcop kdesktop KScreensaverIface lock" to your
"Pause"-key using kmenuedit. That way you can start kscreensaver by
pressing the "Pause"-key.
To explore the possibilities you might want to use kdcop.
Bad idea, posted 12 Feb 2001 at 04:28 UTC by strlen »
UNIX is not a GUI OS, and is not designed to be. When I run X, most of
my applications are simply terminals, and there may be one or two
netscape windows floating around. Yet, your ideas about shell poping up
Windows can be implemented with IPC, communicating with the window
manager/windowing system. Mandrake, I believe, had been working on some
sort of shell named MAW. And IPC based shells could have further
implications as well, beyond the windowing system. Personally, I'm not
interested in the idea of GUI UNIX, but the idea of applications working
together as you suggested is pretty neat.
IMHO not possible, posted 12 Feb 2001 at 09:47 UTC by ali »
There already are such things, and it always were the first things I
My RedHat (6.2, I think) had such features in some system tools: My
user was allowed to shut down the system. When I typed "shutdown -h
now" into a xterm, a small gnome window popped up and asked me for
my password. It first looked like some nice feature and a good idea, but
I quickly started to hate it and eventually turned it off.
found it annoying that I had to look around on the desktop to find the
new window (I typed at the command prompt, got output at the command
prompt, looked for half an hour at the same screen position where
everything interesting happened, and now I have to move my eyes? why?).
Finally, I got personally offended by shutdown (sounds weird,
but is true). I just hated this little bastard program for playing
"catch me!" on the screen.
Another example is AIX: Several system commands do exist in a
"X-enhanced" variant, like "passwd" and "xpasswd".
Same thing applies here: It is too annoying to follow the "point of
interest" on the screen.
Now, to give these rants some bones, for the "tar" idea:
tar wants to display a progress bar (let us ignore for the moment
that tar doesn't always know how much it will do)
First thing is: I desperatly want to use tar when my harddisks fails,
and only my home partition and the root partition are alive. So, tar
must not be linked to the x libs, must not look into some config files
or anything. Thus, the mechanism is rather complicated, most likely
you'll have to write two tars: "tar" and "xtar", and
one starts the other if desired.
Now, to make me happy, you want to solve the point-of-interest
problem. Your progress bar thus always appears directly below my xterm
and is aligned with it. What do you do when I start multiple tar's in
background? (If this feature is supposed to be useful, it should offer
me a solution for the "multiple programs produce output" console
Next, I don't want to always type --do-x</tt> resp. --no-x,
so it looks for a shell variable (like $X_ENHANCED or
something) The problem is: What do you do when I type "tar -z
..."? Whose progress bar is visible? gzip's or
Another problem is the history and cut-and-paste. One of unix's very
cool features, and actually the reason why I abandonded windows, is that
I can scroll up in my xterm, see what happened some time ago, and copy
parts of the output into something else. Lazy as I am, I often use TAB
completion as a "ls-on-the-fly" while I type some directory name, and
later use all the ls's for some cut-and-paste stuff. So a file dialog
would be a disadvantage for me.
Then, pipes. You could of course put in some features that the x
enhanced are turned off if stdout is a pipe. It frequently happens to me
that I do something, and later find out that I needed to pipe the app's
output in the first place, but don't want to restart the same thing
again just to pipe it. So, I can simulate the pipe by just using
"cat" and cut-and-paste. In order to keep that method working,
I simply have to turn off all the x enhancements.
Now, all this doesn't mean that is impossible, it just means
that it would have to be really clever. And <rant>my first thought
on how it would look like is that every time I use tar, the
gnome stuff boots up, destroys my desktop, informs me about my
non-compliant WM, and then crashes (this just happens too often with
so-called clever tools)</rant>
Oh sweet irony: one of the main opponents of the Unix-way of doing
things was a system that has most of the requirements you ask for.
Immagine: a system where everything you write to the screen (or any
other device) gets associated with an object. "ls" would tell the system
"I'm now going to print a directory" and in that printed representation
of the directory "And this is a file", "This is the filename" etc.
The system remembers all of this, and when you give a command to the system the utility
can declared what input it expects. For instance you type "emacs " and the emacs-system
told the screen "I expect a filename (either to a local file or one
on the network; or a stream that is open; or a editable-object of
some kind". If you then would move the mouse over the directory listing the screen would ask each object if it fitted the requirements, and if so it would light up. This was carried through upto the fact that compile-file would only make source files light up...
The system was a Lisp machine, long since dead. But the CLIM GUI still lives on, and after working with it a bit it seems the most natural and easy way of man-machine interface I can imagine.
hmm, posted 12 Feb 2001 at 11:22 UTC by jdube »
Well, firstly, I think that having console is very nice if you have a
slow computer - I mean, that's one of the features unix advocates brag
about. For X11 being controlled completely by keyboard, look at larswm
- you don't really use the mouse at all. You can set up keybindings in
most or all window managers, and if you set them well you can avoid the
mouse - but does this not almost entirly void the point of a GUI? I
think the UNIX operating systems are the only OSes out there that really
give a crap about UI design any more - look at Windows, for example, how
has the UI changed since Windows 95? People like uniformity. Console
and X work well together - besides, I'd be pretty pissed off if every
time I ran a command a new window popped up.
Bonobo, posted 12 Feb 2001 at 13:43 UTC by federico »
Let's say your terminal program sets an environment variable,
TERMINAL_IOR="IIOP:somebiguglynumber". Your tar program sees that this
variable is present. The object that it points to is a Bonobo::Unknown,
naturally. So you do query_interface(obj, "ProgressBar") on it and if
the terminal supports a progress bar display, you get back a reference
to an object that you can use to do progress-barish stuff.
I would suggest that you read the wonderfully insightful essay "In the
beginning was the command line" by Neal Stephenson
(http://www.cryptonomicon.com/beginning.html and other places). It talks
about the relationship between the GUI and the command line, and
addresses many of the comments made both here and on Slashdot.
CLI + GUI = ???, posted 12 Feb 2001 at 16:51 UTC by nymia »
My first reaction was: It makes sense, why not? After all it's just
normal to bring up the system immediately to a GUI environment. Many OS
such as Mac, Windows, BeOS, etc do it already.
However, I think the problem lies not in the metaphor, but, in how the
computing model was designed and implemented. IMO, Unix was heavily
based on theorems and principles of strings and symbols. They are
mostly implemented as functions that manipulate characters, strings and
probably non-ascii chars. State machines and other gather-and-scatter
devices work very well under these conditions as well. All these
elements belong to this domain only, which probably doesn't extend to
the GUI world simply because the computing model there is much more
complicated. In the GUI world, the fundamental element is not the
character, but, something much more than that. It could be interfaces
or objects acting like filesystems where each GUI element is
addressable that can send and receive messages. Frankly, I don't know
what kind of model would I use to create a GUI that would work under
Unix as I'm still figuring it out what constitutes a very good GUI for
I do not have deeps insights into GUisms, comparable with those
offered by our local Berlin-ers. However I do have an interesting
expirience to share.
In my college we used a locally developed OS (MISS),
that was comparable in features to RSX-11/M+ and contemporary
UNIX (BSD 2.9 or SVR2). It was used by students to run their
Fortran (later C) programs, games,
e-mail, store-and forward networking, railroad control, etc.
The thing about MISS was that it had no command line whatsoever,
anywhere in the system. Everything was menu driven, natively.
This actually led to kludges when we started
to port UNIX applications (such as nroff).
When I saw a system with a command line, I was *asnonished*.
The whole concept of "talking" to computer and hitting "Return"
was soo alien that it took a while to grasp. My first difficulty was
to remember what commands exist.
Lessons that I extract from that are:
- Command line is not any more natural than other UIs.
- Absense of a command line does not preclude scripting.
Fist - some comments, then description
strlen - Yea. IPC would be used, and they must be shell controlled (like pipe is now).
jameson - your View/Control could be implemented as shell/stderr(in/out)
RyanMuldoon - If you would do metadata for FS, do not forget
about languages and charsets(Unicode/UTF-8?) in file naming.
Keywords could be implemented now via dir/key/123 (last is link/symlink to file), updated by locate or
dynamicaly generated from database (like dev_fs and proc_fs).
click,drag, right click - RClick - options (edit ~/.toolrc and comand line args(to this instance)),
drag - you could drag file and drop to "grep aaa" , click - select?? , 2click - duplicate(and set options then),
After piping you could see new icon near grep - result. Drag(between -x- prog) - make a pipe "grep|cut" like
Here icons would be just a description - just an icon, not the program, just a package for ordinary command
atai - agree - no GUI inside prog, if one need gui/voice/etc it must create a package around it
but never modify original programm
tackat - KDE commend is too complex, look at cat 'kwite/cmd' |kwrite
or echo "check mail" | kmail or bettre echo "check mail" >~/runing/kmail.1 (named pipe)
ali - in piped variants like cat|grep |gzip - you could have one multi-layered bar :)
becouse gzip progress <= grep <= cat
numiya - but you could make text-described objects :)
cat obj | prog where obj:
Ok. now whole picture.
Modification to standart utils:
In addition to stdin,stdout,stderr make stdstat,stdinfo,stdstatein(stdsi),stdstateout(stdso),
All this made by Shell environment (if shell have no support for it - program will not produce this output).
So you could query via stdsi and receive via stdso information about progress in
different formats - say number or percentage (where apropriate) or number/all.
Of course here you must be carefull not to ask for ALL value - it whould be hard
for piped data or just make all system slow (e.g data came over slow FTP link) - here you may
need some value of speed of geting item to check if it worth of asking for percentage :)
- for real time configuring - it was made by options dialogs/panels (signals stays as they are),
also you could request of sending %-age after every say 10% via stdinfo
or turn it off realtime
Ok - now you see that no compilation with X-libs neded at all!!!
All you need
is Shell aware of this extensions. And it could make status bars in text mode or graphically or in voice
It is for normal piping.... Better IMHO would be to have text-described objects(TDO)
They could go throug MSGS not PIPE-s.
o-grep could mean - grep all messages(type=img) from stream which have property=*value
o-sed could change "whidth=100" to "whidth=200" zooming an image
o-do would get current TDO, and do real modification to image located with "data".
Note!!! main thing is to _pipe-through_ all TDO you are not supposed to understand,
so you coud pipe "total=10/100%","img","10%","img","20%","img"... and last command could draw
a progress bar even if some of TDO was greped out :)
Also you could have running all the time prog with named pipe opend (to shell), so "cat TDO> prog/n-pipe"
will couse shell to get data till EOF and send this TDO via MSGS to runing process.
- static - data file
- TDO - text-described object, wich refers to some data file on disc
- prog-class - package around CMD command (Rclick to edit ~/toolrc and command line arg, except files))
- prog-run - running process , you could drop "kill -9" to it. You could drop TDO on it
- in/out pipe - these attached to prog-run and represents it's stdin/out/si/so for data or TDO
- Lclick - run prog (create prog-run icon)
- L2click - clone icon (but make a copy of file to static and TDO? only! for other - just copy of description)
- Rclick - options dialog - ~/toolrc, switches of CMD , options for prog-run, mode - for static,
edit for TDO options
- drag - static -> in-pipe, TDO -> in-msgs, TDO+static->prog-class+prog-run, prog-class->any icon
(make opposit - like drugging "kill -9 to prog-run"). out-msgs(prog-run)->in-msgs(prog-run)
It must be polished....
Have any one interest in making this a progect? It is not hard to implement. And it is easy for migration from
Egnor: I've decided that I need to write myself a little program which
reports via an X window the number of bytes it's read from its stdin and
written to its stdout. That'll handle the pipe completion (or at least
rate) I'm wanting.
jameson: you're right about a popup window grabbing the focus. On the
other hand, most times you *do* want the newest window to have the
focus. I guess it depends on whether you caused the window to pop up or
not. If it's a "gratuitious" window, it shouldn't get the focus.
stefan: I've got another opinion piece about how every CLI should be
self-prompting. How many years ago did Cisco steal the idea from
Kermit, who sole the idea from Twenex, who stole the idea from Multics?
nether: XMLterm is just too heavyweight. Besides which, there are no
applications that emit XML output, other than xmlcat and xmlls.
atai: tunnel X through ssh. The last real VT100 blew its power supply
five years ago. If you didn't notice, it's because you've been using
xterm exclusively for ten.
federico: Bonobo uses CORBA. CORBA is scary. 'nuff said. :)
Rich: have seen the essay. It's one of the things that prompted my
thoughts on the Unix GUI.
bloat, posted 13 Feb 2001 at 07:00 UTC by turing »
In addition to the various otgher arcane things I do, one of them is
design pretty graphics. I'm a prime candidate to scream "GUIs rule, etc"
I've been a user for the mac forever, and I love 'em.
but, I have to say... what I love about linux has nothing to do with
GUIs. in fact rarely have a need for a gui. why? I'm much better of
with ssh2 and a nice, friendly console :)
I'm sort of inclined towards the (apparently unpopular) view that X
doesn't do very much good simply because it is pretty inferior in terms
of standards and usability to something like the Mac or (dare I say it)
winblows. At least apple imposed draconian rules about how UIs work,
and I think that's the only way to fly in that world.
Now, if only apple would release aqua as opensource! :)
but at the moment, all of the applications I've seen on X don't cut it,
and to tie this in with my title...
I can't remember how big the tar binary is, but I'd be willing to bet
money that the code to run the pretty gui would be five times larger
than the actual application.
anyway, .02c :)