Does the Linux Desktop Innovate Too Much? (Datamation)

Posted Jun 26, 2009 4:15 UTC (Fri) by walters (subscriber, #7396) [Link]

Why isn't there a reliable "ask question" command that pops up a dialog, or a more elaborate "construct this dialog box, let user fill it in, and return when they hit OK"?

zenity --help-question

Posted Jun 26, 2009 6:44 UTC (Fri) by cantsin (guest, #4420) [Link]

Why can't the command line "mail" run my mail setup?

What do you mean with "mail setup"? A configuration dialogue for your E-Mail client or MTA? (If you mean reading your mail, then "mutt" or "pine" does what you ask for. If you have no use for the traditional Unix mail command, you can alias "mail" to mutt.)

Why isn't there an "open" command that "does what double clicking the icon does".

There is - "run-mailcap" (respectively "see"), a command that's probably decades older than Gnome and KDE, or the more recent "mimeopen".

besides why should I have to know what DE I am running

Exactly.

Better yet, why not just have a filename be a "command" to the shells and it acts like double-clicking?

You mean, enter the filename in the shell and have the file opened with the associated program? That's already the default behavior of the shell I use, zsh.

Why isn't there a reliable "ask question" command that pops up a dialog, or a more elaborate "construct this dialog box, let user fill it in, and return when they hit OK"?

man dialog. Dead-easy - there is no simpler way of creating what you describe.

Then scripts could have GUI's.

They already can - see above. For more complex X11-based stuff, there are GTK and QT bindings for all major scripting languages.

Better yet, lots of GUI programs could *call* these programs to do things.

Sorry, but your posting really seems to be the practical proof that the current design philosophy of Linux GUIs cripples, hides and makes people forget what has been possible (and standard) in Unix since its earliest days. Unix is all about that any program can call any another program, redirect standard output and input, and even run nested programs to construct its input parameters.

If Linux programs called something to do the file chooser and users could replace this program, I think within a few months it would go from having the worst file choosers in the world to having the best ones.

Yes, GUI programs would only need to follow the Unix standard of runtime arguments and input pipes, and the file choosing mechanisms could be abstracted and generalized. On the command line, this has been standard since 1969. This is why, for example, all command line programs benefit from the advanced file completion ("choosing") mechanisms of bash and zsh, and not just a handful of hypothetical programs specifically written for one of the two. The nightmare of having a bunch of "bash-native" command line programs and a bunch of "zsh-native" tools, and another bunch of tools which could use neither the advanced features of any of the two shells, is exactly the kind of design fragmentation and usability nightmare existing on the Linux desktop today.

So, yes, KDE and Gnome have thrown out the Unix baby with their GUI bathwater, and created a mess. We still have to wait for a desktop/graphical shell that honors the standard OS mechanisms to give people the full power of Unix.

Posted Jun 26, 2009 6:59 UTC (Fri) by njs (subscriber, #40338) [Link]