Meet Carla Shroder's New Favorite GUI-Textmode Hybrid Shell, Xiki 176
New submitter trogdoro (3716731) writes with an excerpt from Linux Cookbook author Carla Schroder's enthusiastic introduction to what looks like a tempting tool, combining elements of GUI and text-mode interfaces: Command-line lovers, allow me to introduce you to Xiki, the incredibly interactive, flexible, and revolutionary command shell. I do not use the word "revolutionary" lightly. The command shell has not advanced all that much since the ancient days of Unix. Xiki is a giant leap forward. If you're looking for the Next Big Thing in FOSS, Xiki is it. It's not the first tool meant to combine text and graphic interface, but from the screencast demo, Xiki looks like it gets a lot of things right.
Oberon? (Score:4, Interesting)
Not convinced (Score:5, Interesting)
I believe the tradeoff of CLI is between working more efficiently (by typing commands and not having to use your mouse too often to interrupt your flow)
and a steeper learning curve (learn commands and their params, config file locations and their syntax etc.).
This shell seems to provide a lot of features that most of the people are not interested in, or already use specialized tools for those tasks. It is unclear to me why would one prefer to use such a shell to execute SQL or modify the DOM of a webpage rather than spawn a full-featured querying tool, respectively Firebug.
Their syntax coloring looks pretty poor, and they seem to ask you to "double-click" whenever you want to do anything. I am currently using terminator + fish, which I can highly recommend. It makes me way more productive, has very interesting completion features and uses a really large number of colors to make things more easily distinguishable.
The fact that you can move things around is quite cool, but I don't see any significant advantages, although I've only watched the first ~6 mins of video. Can someone competent perhaps voice his opinion on what does this bring?
Re:Not convinced (Score:5, Interesting)
It is unclear to me why would one prefer to use such a shell to execute SQL or modify the DOM of a webpage rather than spawn a full-featured querying tool, respectively Firebug.
Some people are concerned that "traditional" specialized tools have uncomposable interfaces. There seems to be some convergence between this and the Hopscotch interface [bracha.org] pioneered by Gilad Bracha. I believe that the aim of both, despite the two being different in approach, is to ultimately give you the tools to make your own (specialized) interfaces on the fly, rather than to force you into having to deal with multitudes of specialized large windows and to constantly "hunt" for UI elements or displays in a lot of noise.
Re:Not convinced (Score:5, Interesting)
"the tradeoff of CLI is between working more efficiently (by typing commands and not having to use your mouse too often to interrupt your flow)
and a steeper learning curve (learn commands and their params, config file locations and their syntax etc.)."
Solution: use natural language to tell the computer what you want to do. "Copy myfile.txt to mydirectory." "Change my password from old to new." "Change the file permissions on myfile.txt so anyone can read or write to it."
Welcome to Macintosh Programmers Workshop, 1985 (Score:3, Interesting)
The "commands everywhere, hit enter to resample them" existed back then for macintosh programmers Workshop, as many developers will remember. Basically there were no need for real 'scripts', you could type commands, hit 'enter' then hit 'undo' and 'enter' again to re-run it, and yes you could 'execute' anything you selected.
That was the only use I had for the 'enter' key of the numeric keypad of the old mac's keyboard in fact.
So, revolutionary... hmmm. I also reimplemented JUST that as a text-input extension quite a few years ago for OSx, where I could do pretty much exactly that from any text editor on the mac, like SubEthaEdit etc.
Re:Not convinced (Score:5, Interesting)
Please read Robert Heinlein's The Number of the Beast and then tell me if you still think natural language is appropriate to command computers.
The use of natural language to interact with Star Trek: The Next Generation's computer has an extremely powerful appeal. I read Heinlein's novel prior to the debut of STTNG and I was still impressed by the latter, but my belief in the feasibility of the idea is greatly tempered by the former.
Xiki Sucks.. (Score:2, Interesting)
..Because it does not support vim. Also, what problems does it solve exactly?
Re:Not convinced (Score:5, Interesting)
I believe the tradeoff of CLI is between working more efficiently (by typing commands and not having to use your mouse too often to interrupt your flow)
and a steeper learning curve (learn commands and their params, config file locations and their syntax etc.).
For me, the primary benefit of a CLI, when presented by a decent shell, is the flexibility and power of being able to write and run tiny programs whenever it helps.
A CLI not backed by a decent shell is miserable, as was demonstrated by ms-dos.
What's old is new again ... (Score:4, Interesting)
MPW did something similar, only they used their own command set. This had a unique benefit: the output from MPW utilities often included commands that could be executed by clicking on the line with your mouse and pressing enter. It worked very well since the utilities themselves generated those executable commands, and users could extend upon the system with their own utilities. (MPW was a development environment after all.)
Here's the thing though, Xiki cannot do that because its trying to use existing Unix utilities and development tools. While the output from that software is usually intended to be used by other software (e.g. via pipes), it is rarely intended to be used by the shell itself. That means Xiki needs to understand how to interact with each piece of software. As a result, it will end up being an unwieldy mess of plugins and unsupported commands.
Don't get me wrong. The Xiki demos were doing some pretty neat and fairly useful stuff. In that sense, it is a success. The problem is that you'll never be able to use the full power of the metaphor because the software that it interacts with was never designed to interact in the way Xiki needs it to.
Re:Welcome to Macintosh Programmers Workshop, 1985 (Score:5, Interesting)
Re:Not convinced (Score:4, Interesting)
No, it didn't.
Tab completion made it okay. DOSShell just helped to make things less painful to re-run something that was run in the past. And that's assuming that you already ran DOSShell in the past.
Of course, that didn't come along to consumer-targeted operating systems until after the turn of the century, and by then MS-DOS was just a bundled component of some product named after a graphical interface.
For those who wanted a decent shell before then, JP Software's 4DOS was the best option. Those who had a copy of certain versions of Norton software may have been familiar with this product by the name NDOS. These products provided more functionality and were able to use less of the most scarce categorization of memory.
Regarding what can't be done with a .bat file, the answer is: nothing. After all, a batch file could run LoadLin which could load Linux. However, what couldn't be done without a batch file if you weren't relying on external executable files? A lot. Getting user input comes to mind.
I'm fully aware of what can be done with batch files. For fun, I wrote a virus in batch, targeting a specific computer lab so that the software would spread among floppy disks from one machine to another, infecting both hard drives and floppies. The software even backed up changed files (like AutoExec.bat), and checked for a parameter to run a cleaning subroutine that would restore the unaffected files. Despite such accomplishments, I never felt like Batch was a versatile as, well, anything else I've used, including BASIC. User input and conditions were not easily handled.
Re:Not convinced (Score:4, Interesting)
A CLI is simpler and more regular than natural language, and succeeds in allowing complex instructions to be expressed in few words.