The Wayback Machine - https://web.archive.org/web/20170628191310/http://www.advogato.org/article/242.html

Are Unix GUIs all wrong?

Posted 11 Feb 2001 at 16:14 UTC by nelsonrn Share This

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 not?

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 focus-follows-mouse).

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 » (Journeyer)

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?

MVC in all programs?, posted 11 Feb 2001 at 17:04 UTC by jameson » (Master)

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 experimental stage.

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.

Needs more thought?, posted 11 Feb 2001 at 17:56 UTC by RyanMuldoon » (Journeyer)

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.

Ceci n'est pas une pipe, posted 11 Feb 2001 at 20:36 UTC by stefan » (Master)

jameson, let me humbly direct your attention to the berlin project. MVC is one of its 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 modifications and adaptations he could apply. 'Keep it simple, stupid !'.

Some programs, posted 11 Feb 2001 at 21:51 UTC by nether » (Journeyer)

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".

On the subject of keyboardability, posted 11 Feb 2001 at 22:15 UTC by RyanMuldoon » (Journeyer)

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.

Beauty of Unix (usable without GUI) must be kept, posted 12 Feb 2001 at 01:14 UTC by atai » (Journeyer)

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 optional added-ons.

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.

Some of this already works in KDE 2, posted 12 Feb 2001 at 02:29 UTC by tackat » (Master)

> 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:

--snip--

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'

--snip--

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 » (Journeyer)

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 » (Apprentice)

There already are such things, and it always were the first things I turned off:

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.
I just 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 problem)

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 tar's?

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>

A blast from the past, posted 12 Feb 2001 at 10:51 UTC by pvaneynd » (Master)

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 » (Journeyer)

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 » (Master)

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.

In the beginning ..., posted 12 Feb 2001 at 14:11 UTC by Rich » (Master)

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 » (Master)

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 Unix.

Non-command line UI is feasible [], posted 12 Feb 2001 at 22:40 UTC by Zaitcev » (Master)

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.

New model for GUI seamless integration..., posted 13 Feb 2001 at 00:23 UTC by Malx » (Journeyer)

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:

type=image\n
enctype=gif\n
width=100\n
height=200\n
data=/usr/.../aa.gif\n

===========Idea===========================

Ok. now whole picture.
Modification to standart utils:
In addition to stdin,stdout,stderr make stdstat,stdinfo,stdstatein(stdsi),stdstateout(stdso), stdcfg
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 :)
stdcfg - 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.

========GUI=========

Icon

  1. static - data file
  2. TDO - text-described object, wich refers to some data file on disc
  3. prog-class - package around CMD command (Rclick to edit ~/toolrc and command line arg, except files))
  4. prog-run - running process , you could drop "kill -9" to it. You could drop TDO on it
  5. in/out pipe - these attached to prog-run and represents it's stdin/out/si/so for data or TDO
Action
  1. Lclick - run prog (create prog-run icon)
  2. L2click - clone icon (but make a copy of file to static and TDO? only! for other - just copy of description)
  3. Rclick - options dialog - ~/toolrc, switches of CMD , options for prog-run, mode - for static, edit for TDO options
  4. 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 current state.....
Mail me...

Thanks for all your comments, posted 13 Feb 2001 at 05:05 UTC by nelsonrn » (Master)

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 » (Journeyer)

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 :)

_a

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page