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