Slashdot Mirror

← Back to Stories (view on slashdot.org)

Meet Carla Shroder's New Favorite GUI-Textmode Hybrid Shell, Xiki

Posted by timothy on from the shades-of-some-others dept.

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.

38 of 176 comments (clear)

  1. Oberon? by K.+S.+Kyosuke · · Score: 3, Interesting

    It looks a bit like Oberon, only without the live graphics objects goodness. (Although admittedly, the "output right behind the command" is more like Smalltalk workplaces...)

    --
    Ezekiel 23:20
    1. Re:Oberon? by ttucker · · Score: 4, Informative

      His point is: learn to fucking spell "Oberyn"

      That is an uncivil response to a simple error.

  2. Next Big Thing! by Anonymous Coward · · Score: 2

    That phrase in particular is a pretty serious red flag. It is an obvious attempt to gain publicity and/or investment for something which is nothing particularly novel or new or useful.

    If I'm wrong, and the thing is actually practical, please, don't use idiotic tired red-flag buzzwords like that. It turns smart investors off.

    1. Re:Next Big Thing! by Anonymous Coward · · Score: 2, Insightful

      Yawn; wake me when I can get the code from github.

      Did you even look? It takes two seconds of scanning TFA to find the github page.

  3. Not convinced by mstefanro · · 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?

    1. Re:Not convinced by K.+S.+Kyosuke · · Score: 4, 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 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.

      --
      Ezekiel 23:20
    2. Re:Not convinced by blue+trane · · Score: 4, 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."

    3. Re:Not convinced by Noah+Haders · · Score: 2, Funny

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

      first you have to say "OK Google" (or "hey SIRI" if you're a hiptard)

    4. Re:Not convinced by mstefanro · · Score: 3, Insightful

      I am skeptical to the idea tbh. For commonly used commands the effort of learning them is relatively small and the rewards are great (if I ever had to type "change the permissions such that" instead of "chmod" I would just give up and use GUI) .

    5. Re:Not convinced by fnj · · Score: 4, 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.

    6. Re:Not convinced by ShanghaiBill · · Score: 5, Insightful

      Other advantages of a CLI:
      1. You can save the sequence of commands in a script, edit the script, and re-run it later, perhaps on different computers.
      2. You can run commands in a remote SSH session.
      3. You are learning skills that are applicable across a wide variety of Unix-like OSes.
      4. You are learning to use powerful and flexible tools that can be piped together to automate complex tasks.

    7. Re:Not convinced by Capt.Albatross · · Score: 4, 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.

    8. Re:Not convinced by epyT-R · · Score: 2

      which quickly gets tiresome because of how much text you end up typing.

      instead of:
      passwd
      cp myfile.txt /dir/
      chmod 777 myfile.txt

    9. Re:Not convinced by sootman · · Score: 2

      Agree. I watched the "can your shell do this?" video and saw nothing that I would want a shell to do.

      He built a shell that does cool things he wants? Great. I could build a shell that does neat things I want it to, but I don't think anyone else would want to download it.

      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    10. Re:Not convinced by FuzzNugget · · Score: 2

      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)

      If they did it right, one should be able to navigate entirely using the keyboard, the mouse being optional.

    11. Re:Not convinced by vtcodger · · Score: 5, Insightful

      Solution: use natural language

      Interesting idea. ten to one, you would get a great lesson in how ambiguous "natural language" is. A language that does not distinguish between inclusive and exclusive OR, has no rules for resolving the order/priority of ANDs and ORs when both occur in a clause, and which has a rather cavalier approach to NOT ("Isn't the door open?" is likely to mean "I think the door is open" rather than "Is the door closed?") may not be the ideal medium for communicating your wishes to a box.

      --
      You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
    12. Re:Not convinced by Livius · · Score: 5, Insightful

      Solution: use natural language to tell the computer what you want to do.

      Because we all know that all programmers do is follow the requirements document from the client, which never requires any clarification/investigation/analysis/follow-up/etc.

    13. Re:Not convinced by phantomfive · · Score: 3, Funny

      And what can't be done with a .bat file?

      Every time I have to write a .bat file, I consider whether it would be more comfortable to stab myself with a fork. After I am done, the answer is always that I'd rather have stabbed myself with a fork.

      --
      "First they came for the slanderers and i said nothing."
    14. Re:Not convinced by Anonymous Coward · · 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.

    15. Re:Not convinced by mwvdlee · · Score: 2

      I for one am constantly aching for a CLI that can play musical notes. It's an essential feature and one I cannot possibly do without.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    16. Re:Not convinced by lars_stefan_axelsson · · Score: 5, Insightful

      And also something I came to value when working in industry and developing both cli and GUI admin tools for telecoms equipment:

      You can easily document, email and (to a lesser extent) talk about a cli. A GUI not so much. When you've tried to walk someone through finding the hidden option in a GUI over the phone for the tenth time you're ready to tear your hair out. With a cli you can just email some commands and that's that. Documenting a GUI invariably devolved to a lot of screenshots which makes any workflow tens of pages long, instead of ten lines of commands which you then have ample space to explain and comment on. It's also much easier to read and follow along as you're e.g. installing, than leafing through screenshot after screenshot.

      --
      Stefan Axelsson
    17. Re:Not convinced by martin-boundary · · Score: 3, Interesting
      Unfortunately, natural language is less powerful than the CLI. The problem is that it is very difficult to express a sequence of instructions in a natural language. Very quickly, you end up with paragraphs full of clarifications, which look very much like legal documents (legal documents are in fact an early attempt at using natural language to express precise ideas - and it just doesn't work very well either).

      A CLI is simpler and more regular than natural language, and succeeds in allowing complex instructions to be expressed in few words.

    18. Re:Not convinced by smittyoneeach · · Score: 3, Funny

      You probably aren't using enough Object Oriented Programming. I mean, XML. I mean, Agile Methods. I mean, Big Data. I mean, Cloud. I mean. . .

      --
      Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
  4. Welcome to Macintosh Programmers Workshop, 1985 by buserror · · Score: 2, 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.

    1. Re:Welcome to Macintosh Programmers Workshop, 1985 by Darinbob · · Score: 2

      But go back in time further and people were experimenting with graphical interfaces combined with a CLI. Even the Smalltalk 80 systems could be said to be an integration of graphical interface with a command line (the command line being the "workspace" window). And of course Lisp machines and their combined graphics with a more conventional CLI.

      It's sort of like the history of computing is completely blank to people before the introduction of PC and Macintosh. Or maybe it's Babbage and Lady Lovelace, then a missing century where nothing happened, then poof, the PC and DOS appears.

    2. Re:Welcome to Macintosh Programmers Workshop, 1985 by Mostly+a+lurker · · Score: 4, Interesting

      Believe it or not, using 2260 terminals connected to an IBM 360 mainframe running MVT/ASP, I was able to rerun commands anywhere on the screen back in 1973!

  5. Xiki Sucks.. by Anonymous Coward · · Score: 2, Interesting

    ..Because it does not support vim. Also, what problems does it solve exactly?

    1. Re:Xiki Sucks.. by smallfries · · Score: 4, Informative

      Also I went through a phase of doing most of this inside vim anyway. It was a time when I was doing a lot of string manipulation in bash with long complex pipelines and I needed to explicitly show the state / track the output of each component.

      In vim you just need to keep a :r! at the beginning of each command line, to execute just check that you are in command mode with esc then select the cmd line and middle click to execute, allows piping in results by selecting the input and dropping the r to get :!. There is no support for custom hit regions for the mouse, but in compensation it works everywhere already.

      If you already use vim, then having access to vim motions and commands to edit output makes for a surprisingly good shell.

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
  6. Too many security issues. by shellster_dude · · Score: 5, Insightful

    The command placement and directory browsing is cool, but I don't want any command line that accidentally runs things when I click on them. I don't want any command line that tries to interpret my input as multiple scripting languages. Both of those sound like a security disaster.

  7. what if you could.... by Trailer+Trash · · Score: 4, Insightful

    nut kick the guy who keeps asking "what if you could...." in the screencast? That got annoying real fast.

    --
    Do you have ESP?
  8. What's old is new again ... by MacTO · · Score: 3, 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.

    1. Re:What's old is new again ... by Darinbob · · Score: 2

      This was something done with Lisp Machines as well. Symbolics Inc with their Genera operating system combined CLI with the GUI, and you could get a list of valid command options and then either click on the option you want or just type it in.

    2. Re:What's old is new again ... by trogdoro · · Score: 5, Informative

      There's a simple metaphor of "text-in, text-out" that xiki stays true to. It interacts with shell commands, scripts, text files, just about anything. You can call a shell command directly, wrap some lightweight code around it let its output be interactive, or wrap a full script around it. > it is rarely intended to be used by the shell itself I'm going to be post a new video very soon showing a new way of jumping quickly back and forth between your standard shell and Xiki, and making them work together, which I think is a missing piece that solves some of the awkwardness you allude to. I wish I'd gotten it out there before this thread!

  9. Re:Ho.. hum by trogdoro · · Score: 5, Informative

    Indeed. It's been out there, and I've been doing live demos of it for years. At RubyConf, QCon, Strange Loop, and about 20 usergroup presentations. The problem is the installer sucks, and people are confused by how to start using it, which the Kickstarter is meant to address. I'm going to post a new video showing some progress on addressing the latter issue very soon.

  10. Re:Onions have layers...shells have layers? by jrumney · · Score: 3, Funny

    ...which is run from within my editor of choice, emacs.

    ...which I run in a shell.

    You seem to be confused about the program that emacs is replacing. It is not replacing vi, it is replacing init. Once you realize that, you will find it perfectly natural to run your shell inside Emacs.

  11. ithkuil by SgtChaireBourne · · Score: 2

    "natural langauges" are too imprecise. Even native speakers often get confused talking to each other. It's just that most people don't notice the back and forth with clarifying questions since it comes "naturally". It seems that for any high level of natural language processing a fully sentient AI would be needed for the interpreter.

    An interesting experiment might be to use ithkuil for the UI at first to reduce ambiguity and imprecision. That might make it easier to gauge how much AI would ultimately be needed.

    --
    Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
  12. Commodore by Lorens · · Score: 2

    The "commands everywhere, hit enter to resample them" existed back then for macintosh programmers Workshop

    The Commodore interface was like that too.

  13. Re:The Xiki Wiki by camperdave · · Score: 2

    ... but it still won't get you a hickey.

    --
    When our name is on the back of your car, we're behind you all the way!