Slashdot Mirror
Are Unix GUIs All Wrong?
BrightIce writes "Advogato has an interesting article about GUIs on Unix. The basic message is that it is wrong that the command line is "a completely seperate world" and proposes some interesting ways CLI and GUI could cooperate." The feature actually isn't all that long - but I'm sure the discussion can get going from there.
It may be one of the Mac's strengths... But it has also been one of the reasons why the Mac has been a failure.
Those of us who are adept with computers do not appreciate the way the Mac treats everybody as an idiot. I've found the Mac incredibly frustrating to use over the years, but that's not to say I wouldn't recommend it to a friend I didn't want calling me for help. Thus the problem is the adept people who might actually support and write software for the Mac universally despise it, which can't help it's marketing.
Granted, Windows started down the path of everybody is an idiot. But then most people are. But Windows also provides you with the other tools one needs to actually dig down in deep and do your work. So it's simple enough for idiots, powerful enough for programmers.
Now Unix on the other hand has the unique distinction of being the OS for everybody but idiots. It's elitist, but it works for some people.
So we have a different OS for everybody, and obviously the one which has taken the middle ground is the most popular.
The problem I see is that if Unix starts going down the path of Windows, it will simply become Windows.
And at that point, why not just save a lot of effort and use and improve Windows to begin with?
I've never been a big fan of the Linux everywhere argument, I think it's silly.
You have a good point, a very good point. If Unix is so good at pasting tools together, then there's no need for tar to be modified. Okay, how about this, then:
xprogress gzcat files.tar.gz | tar xf -
xprogress would stat stdin, fork the rest of its command line with stdout going through a pipe, and show a progress bar over the length of the file.
But that's just tar. There's a bunch of other things I'm wanting.
-russ
Don't piss off The Angry Economist
What I would like to see is a combination of both of these. For example when I am browsing around in a file manager, sometimes I want to just rightclick and delete a file or something simple. Other times I want to type in a script name to run on the file. I think the best way to do this would be to have a command line space on the bottom of the file manager. The command line space's working directory would be whatever the current working directory in the file manager is. Then I can do my gui stuff in the file manager, and then type in stuff on the bottom if I needed to. Basically a bash shell whos working directory stayed in synch with the file managers directory. It's the best of both worlds.
Outdoor digital photography, mostly in New Engl
KDE 2.0 already claims you can do anything from
the keyboard and the object model supports
scripting. Also, most KDE 2 applications even
allow you to use regular expressions every place
they might be useful--as an option (not a
necessity).
I absolutely agree that the philosophy of small
tools should be expanded to GUIs, but I think
KDE is doing this. The QT toolkit's signal and
slot philosophy is a near parallel and KDE
componant objects nearly complete the
requirement.
The old OS-9 operating system (used on CoCo's and
some M68000-based computers like Atari ST) also
had an interesting philosophy for GUIs.
You could pipe data in and out of every Window
and all kinds of GUI activity could be managed by
character streams all centered upon ASCII.
It was an excellent philosophy. Last I checked,
OS-9 was still marketed for embedded systems.
This is the OS-9 of Microware systems
corporation--not the MacOS 9
--Matthew
If we don't do that soon, Unix on the desktop is doomed
Je t'aime Stéphanie
- What if I'm logged in remotely? Doesn't this assume I have a graphic terminal?
- Won't this cause random stuff popping up when, say, cron scripts run?
No, boneheads! Just provide a standard switch that means "don't do that GUI shit". That may be a problem for our current set of Unix tools, since it is probably impossible to find a switch that is unused in all Unix tools. But that doesn't preclude someone from implementing this idea in their new operating system, where the switch meanings aren't set largely by tradition.--
SecretAsianMan (54.5% Slashdot pure)
Washington, DC: It's like Hollywood for ugly people.
I think this is a valid argument. For example, when I log into my school UNIX account to use Matlab from the console, I use the program as a console program. When I log in while in X, Matlab detects that and allows me to use all the nifty graphical stuff too. I know there are other programs that do this same thing too... emacs, etc.
Why couldn't "normal" programs do the same thing. It wouldn't hurt cron jobs and the like (as everybody keeps complaining about), because the cron isn't run on a terminal per se, and therefore the cron programs wouldn't have access to X.
I'm sure there could be an easy way to implement a "i-don't-want-this-program-to-use-x"... perhaps a simple alias would work. example) alias tar="tar --noX" or something like that. The only problem I see with this is that it would require a rewrite of a bunch of stuff, but I'm sure there are coders who enjoy stuff like this (I'm up for it if people will help).
It would make the GUI more informative. On "other" desktops, when I'm copying a bunch of files and it's going to take a while, I get a nice little progress bar... I like that. I know it's standard in UNIX that "no output is a good thing". But if a User is sitting behind a GUI, it's obvious that they're looking for output when things are going to take a while.
Just my $0.02.
One way to implement such things would be to write a replacement for xterm and define a new terminal type. Just as xterm has escape codes to set the foreground and background colors, the new termi nal could have additional escape codes to create or update certain display widgets. I'd rather such widgets were part of the terminal window than poppped as separate windows, which sounds somewhat uncontrollable. You'd also need a good scheme to kill the widgets if the process that requested them dies . If done this way, the gui enhancement would still work well over a 300 baud modem.
If you're using a terminal that doesn't support these capabilities, the termcap database wouldn't return any codes for them, and everything would work as it used to.
I used to use AutoCAD heavily, and I liked its interface, which was something like a Unix shell with the ability to mix mouse clicks with words, and to see the results of commands after you typed them. Imagine if you type 'ln -s
I got seriously into the Mac back in 1984. One thing that always struck me as wrong was the way Windows was built on top of DOS.
I mention the following because it is quite a different philosophy that is probably foreign to most unix people.
Similarly to DOS/Windows, but without so many problems (or maybe with different problems), X is built on top of unix.
In Mac, the GUI is fundamentally part of the OS. There is no command line. Period. Well okay, there is. It's MPW. But it's an optional add on. But it runs on top of the OS and GUI. It is a powerful CLI environment with a rich set of utilities, compilers, disassemblers, make, sed, grep, command piping ala. unix, etc., ad nauseam. MPW's cli is executed in a window(s), but NOT in the same manner as Xterm, as you might expect. (Take too long to explain here.)
The important point is that the CLI is on top of the GUI, not underneath of it.
Please don't misinterpret me here. I'm not suggesting that one way or the other is wrong. Both have advantages. Linux is great as an embeddable OS. Just change the init scripts, or even the init program itself. You can use the OS for completely non-gui things. (Or non-cli for that matter.)
A property of Apple's approach is that the GUI is not an afterthought. User friendliness is thought of first and foremost in everything. (The mouse, it's drivers, etc. are fundamental parts of the system -- not add on's.) This may be why the Mac has the legendary ease of use. And why it took so long for Microsoft with their opposite approach to achieve a similar level of friendliness.
If you want to build gui-less tools (on Mac) that cannot be run by end users, then compile your program as an MPW tool. Most end users don't bother to get MPW. So your gui-less program automatically has a very limited audience. Just try writing a gui-less program for the mac. There just are no such concepts as "standard input", "standard output", etc.
It's interesting that Apple is completely turning the system on it's head in Mac OS X. This is probably a good thing for software portability. But a large part of the world is missing having studied the different approach of the classic Mac OS. (Not that it's necessarily right, it's just different. Observing the workings of other systems, languages, etc. enriches you.)
I'll see your senator, and I'll raise you two judges.
There were some good points made in the article. But should we be bloating programs like tar with window manager cooperability? Hell no! I don't even think that tar should have the -z option, as it can just be piped to gzip anyways. I see no problem with an alias to do it, but tar should be considered a completed product, it does what *it is supposed to do*. This is a major accomplishment with a program. If you want it to do something else build a script that runs on the UI.
The power of UNIX is that it has all of these 'infrastructure' type programs upon which so much more can be built. There is no reason to build an extra program within a program. This just adds complexity which the UNIX design is against. If you look into the history of UNIX you will see that it has always favored stability over speed, and a small program that does what it is supposed to do rather than one large bloated 'featureful' program. Why should we get rid of the UNIX design philosophy when making a UI? It doesn't seem logical. As UNIX is an bottom up system so should be the UI (and it has been).
People who are selling UNIX by saying that our UI is just a good as XX's are morons. We are really forgetting our strengths. A person could build an excellent windowed compression/decompression program that can drag and drop to other programs, without having to know how to write a compression program, how to write a window environment, or how to figure out drag and drop. To them, it is all pipes. I'm not saying that XX's products don't have these characteristics, but to UNIX it is so much easier to do. Lets not ignore this power.
Taking the gecko engine (or whatever they call it now, 'nslayout or something') and making your browsers render with it rather than writing a new engine for yours, using X to render rather that using the framebuffer in different ways (it seems really stupid to me to make a window manager in UNIX that can't be networked), or making a script to run tar and gzip in a friendly graphic way is my opinion on how UNIX GUI's can be a sucess. Adding a completion bar to tar and using a --nodisplay flag is not.
Suddenly, the hairy finger of a familiar monkey tapped me on the shoulder. It was time.--G. T.
While I find some of your arguments here have merit, I believe that you're looking at this with a sort of CLI blinder on. That, and breaking your post up into paragraphs would certainly help it's readability.
Yes, many applications that are GUI only tend to be so not due to any need beyond that's where the audience is. Folks used to think, why in the world would I need a spreadsheet run from a GUI? Then those same folks got to seeing all the other information that can be derived from changing a cell color, altering a font, or porting the information to a variety of graphs. Let's face it, the GUI spreadsheet was the real selling point of Windows back in the early days.
As to remote access, from a dial up modem I'm able to log into my office computer running NT and LapLink and utilize it. Delays in typing up stuff like E-mail is annoying, but only slightly more so than logging in via SSH to a remote BSD box and typing in Pine. In each case it just ain't like being there when you're doing the dial up thing.
I will firmly agree with one point you seem to be driving at though. There is an over reliance upon the mouse in many GUI based apps that actually hinder the usability. I personally find that NT does a better job of keyboard support than either KDE or Gnome. Of the two, I find that KDE seems to do a better job with keyboard support, but there's a fair amount of work still to be done.
As a FreeBSD user, I personally don't see a lot of front line CLI based office apps for it. No, I do not count EMACS as a word processor. Nothing even approaching the level of VisiCalc on the spreadsheet front either. I'd love to see more work done on this myself, but the fact is that most folks today simply don't feel comfortable unless there's a GUI running the app. The only thing that will even dent this kind of paradigm are compelling tools for a CLI that folks will want to use. No amount of preaching will have as dramatic an impact as that.
The line must be drawn here. This far. No further.