Lea: The Unity design process (and how you can play a part in it)
Lea: The Unity design process (and how you can play a part in it)
Posted Feb 18, 2012 2:04 UTC (Sat) by tshow (subscriber, #6411)In reply to: Lea: The Unity design process (and how you can play a part in it) by dlang
Parent article: Lea: The Unity design process (and how you can play a part in it)
I've got a boil-the-ocean project to fix this, but I haven't had the time to get it to the point where it's worth putting out there.
To give you a sense of the sort of thing I'm thinking of, consider a standard terminal session. You type a command, it executes, produces some output, you get control back. Standard REP loop stuff.
Now, imagine each cycle of the REP loop is in a bubble. A bubble you can tear off and put somewhere else on the screen. Or name, and pipe things to/from. Imagine if when you launch a command, it "backgrounds" immediately, but to its bubble, so it can keep outputting to the bubble without messing up the current command, or intermixing destructively with other commands.
Imagine if you could hook up DBus services trivially as pipeline stages.
And the terminal has a richer vocabulary, so it's capable of generating (and later updating) things like progress bars, or other simple widgets. Or can say "make this mouse-active and launch this program with that as an argument" so filenames and urls and the like can be mouse-active. Or "this bit is block text, so typeset it nicely in a proportional serif font", while having monospace text for all the interactive stuff. Or nesting levels, so you can navigate program output hierarchically.
If programs using the shell had some standard calling convention (like, say, --describe-args) that would output a machine parseable argument tree, so the shell autocomplete would know that -f expects the name of an existing file. And which would provide data the shell could typeset into proper, modern manual pages.
Imagine a robust scripting language and support for interactive function editing, so you can build up a library of useful functions and tweak them as you need. Being able to type simple math on the command line and have it evaluate without having to jump through syntactic hoops.
Imagine being able to highlight something and run a command on it which substitutes the result for the highlighted area; like interactive backquotes.
And have the shell backed by a daemon, so you can attach/detach as with screen, even if the session is on a different system.
That's just a fraction of the plan, really. The whole idea takes pages. The idea isn't to replace the existing desktop, it's to provide a powerful tool for controlling whatever desktop you choose to use.
Ultimately, if I can build it, it replaces bash, man, info, xterm, screen, emacs and a whole host of other stuff. So it's a boil-the-ocean project in every sense. But I think it's worth building.
