Forgot your password?
typodupeerror
GUI Open Source Linux

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

Posted by timothy
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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Oberon? (Score:4, Interesting)

    by K. S. Kyosuke (729550) on Friday June 27, 2014 @06:08PM (#47337425)
    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...)
  • by Anonymous Coward

    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.

    • Practical? Take a look:
      https://www.youtube.com/watch?... [youtube.com]

      It looks like it just recognizes bash commands and dumps their output into the text buffer. You can then cut and paste it! You can even 'edit' the output: the example shows `df` returning 22% room free on the disk, and the user 'edits' it to 42%. Sounds practical, no?

      For those already on VIM: Prefix your commands with `:r!` and VIM will already do this. Granted, you already need to know that `:` starts a command, `!` runs a Bash command, and prefixing

      • For those already on VIM: [...]

        I already do something similar in VIM, and xiki is far from been the same as ":r!". You probably should watch the first screencast [xiki.org].

        The xiki thing is basically a Ruby shell, with built-in free-form text editor. But primarily it is a wrapper around the Ruby. Thus it limits its appeal to mostly Ruby users and developers.

        The concept is definitely interesting. It basically brings back to CLI some capabilities that many have given up to GUIs. Adding something like this to an editor like VIM is definitely poss

        • Thank you. I've watched the screencast but I really do fail to see any utility in Xiki, only novelty. Can you describe something that Xiki can do that cannot be done with `:r!`? I would really love to add Xiki to my toolbox if it is useful, but I fail to see that.

          • Can you describe something that Xiki can do that cannot be done with `:r!`?

            I can't. Because I do not use Xiki. I use something much simpler coded in VIM.

            But the paradigm as I use it, in VIM terms: the command and the output are kept in the same editor window. You can apply exiting VIM functions to both - commands and output. You can save and load both at the same time - since in the essence it is an ordinary text file. With a special ':g//' I can rerun all the statements in file at once. Or I can selectively rerun only particular ones by the mask. I can ':w' and it is all made p

            • Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.

              I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate

              • I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate

                Well, you really have to try it first to understand the difference.

                Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inlin

                • I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate

                  Well, you really have to try it first to understand the difference.

                  Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.

                  And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.

                  Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)

                  I've used emacs for that (editing 'uneditable' things in the buffer and then re-executing). See my post above - handy link here [slashdot.org]

                  • I've used emacs for that (editing 'uneditable' things in the buffer and then re-executing). See my post above - handy link here [slashdot.org]

                    OK. You completely miss the point.

                    Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.

                    Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.

                    • Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.

                      Well, perhaps my emacs is broken then, because it lets me type anywhere and accepts the line as a command upon pressing enter. I can also scroll up and position the cursor on any line in the emacs window and press enter and it will accept that line as a command to execute, even if that line was not a command previously but the output of a command.

                      Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.

                      I'm afraid you are correct - I simply cannot see anything in that video which I cannot also do using a shell from emacs, and I'm way too lazy to make and post a vi

          • Thank you. I've watched the screencast but I really do fail to see any utility in Xiki, only novelty. Can you describe something that Xiki can do that cannot be done with `:r!`? I would really love to add Xiki to my toolbox if it is useful, but I fail to see that.

            If you want something better than :r! in vim, use emacs as a shell. I used emacs as a shell for years - you can cut-n-paste (multiple buffers), use the mouse to mark regions, save the entire session as a file, load a previously used session, search back, search forward, edit previous commands before running them, edit the output of previous commands (and then run them), execute the odd elisp expression (need a calculator quickly? It's built in), surf the web, read/send email, read usenet (or read slashdot),

  • Not convinced (Score:5, Interesting)

    by mstefanro (1965558) on Friday June 27, 2014 @06:23PM (#47337529)

    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)

      by K. S. Kyosuke (729550) on Friday June 27, 2014 @06:34PM (#47337603)

      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)

      by blue trane (110704) on Friday June 27, 2014 @06:37PM (#47337615) Homepage Journal

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

      • Re: (Score:3, Funny)

        by Noah Haders (3621429)

        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)

        • by vux984 (928602)

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

          Honestly, all things considered "Siri" is far less obnoxious to say than "OK Google" in my books.

          • Google makes it clear you're talking to a corporation, Apple forces you to anthropomorphize your machine. Match goes to Google.

            • by vux984 (928602)

              Google makes it clear you're talking to a corporation

              Yeah, and that's part of the problem right there. I don't want to be talking to a corp... 90% of what I'd consider using voice for shouldn't need internet. I'd like voice-recognition on, but give it no internet access.

              Make calls, answer calls, add stuff to calendar, send a text, look up a contact, etc... nothing should need to go to google.

              And I'd be ok adding a keyword "bing" or "google" to any search that specifically needed to go there.

              e.g. hey phone,

              • to boot, you don't actually have to say "hey siri". you can just tell it what to do. I really like siri. it's great for some things, and if you just use it for those things then it's great. I use it all the time to set a timer. hold down home button, "set a timer for 20 minutes from now". Or "set an alarm for 7:30 tomorrow morning". it's much faster to do this than to unlock your phone, open the timer app, etc.

                it's also good when I'm walking and want to shoot a quick text message "text Frank I'm running 10
      • Re:Not convinced (Score:4, Insightful)

        by mstefanro (1965558) on Friday June 27, 2014 @06:50PM (#47337703)

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

      • Re:Not convinced (Score:5, Interesting)

        by fnj (64210) on Friday June 27, 2014 @06:50PM (#47337707)

        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.

      • by epyT-R (613989)

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

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

      • Re:Not convinced (Score:5, Insightful)

        by Livius (318358) on Friday June 27, 2014 @09:04PM (#47338349)

        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.

      • Natural language is both ambiguous and unprecise.

        Converting it to a programming language forces you to be specific about what you really want.

      • I'm all for the natural language approach. I'm holding off til I can say something like "give me a histogram of all occurences of this regex across all files in subdirectory X....". Til that time it's a pipeline of grep/sort/uniq.

      • by stjobe (78285)

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

        It's hard to wreck a nice beach.

      • Re:Not convinced (Score:4, Interesting)

        by martin-boundary (547041) on Saturday June 28, 2014 @04:04AM (#47339389)
        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.

      • I was writing on my notepad when I put the baby in the playpen to calm her down. Then I discovered the pen was not working.

        Natural language can be pretty vague. Talk to a programmer who takes down a ISP router with a misplaced semicolon on how strict they can be. Computers are not smart enough yet to do true natural language. When Watson can answer every single question, maybe.

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

      you say that your terminal interface makes you more productive, and yet here you are commenting on slashdot. which one is it?

    • Re:Not convinced (Score:5, Insightful)

      by ShanghaiBill (739463) on Friday June 27, 2014 @07:05PM (#47337779)

      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.

      • Re:Not convinced (Score:5, Insightful)

        by lars_stefan_axelsson (236283) on Saturday June 28, 2014 @03:54AM (#47339377) Homepage

        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.

      • This and lars_stefan's reply are right on. Its amazing how often I've worked my way through scripting a sequence of shell commands that gives me the result I want, then I either save it as a shell script for later, or execute it on a remote machine or send it to a colleague by E-mail with "run this to find out who's E-mail is clogging the pipes" or something.

    • Re:Not convinced (Score:5, Interesting)

      by Capt.Albatross (1301561) on Friday June 27, 2014 @07:14PM (#47337821)

      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.

    • by sootman (158191)

      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.

      • by mwvdlee (775178)

        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.

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

  • by buserror (115301) on Friday June 27, 2014 @06:40PM (#47337639)

    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.

    • by Mostly a lurker (634878) on Friday June 27, 2014 @09:10PM (#47338373)
      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!
    • The "commands everywhere, hit enter to resample them" existed back then for macintosh programmers Workshop

      The Commodore interface was like that too.

    • Or, or: CTRL+R and keyup.

      If you take away the mouse in this newfangled interface, I bet CTRL+R and keyup require fewer keystrokes on average than moving the cursor to the command you want to re-run. Granted, CTRL+R and keyup could be slightly less destructive in certain cases, but other than that they're pretty much perfect.

  • Xiki Sucks.. (Score:2, Interesting)

    by Anonymous Coward

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

    • Re:Xiki Sucks.. (Score:5, Informative)

      by smallfries (601545) on Saturday June 28, 2014 @03:22AM (#47339327) Homepage

      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.

    • by iluvcapra (782887)

      Also, what problems does it solve exactly?

      It is yet another attempt by Rails developers to construct a web app IDE that squares with their idealism.

  • by shellster_dude (1261444) on Friday June 27, 2014 @07:12PM (#47337803)
    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.
  • So, lemme see if I have this right.

    This is a new take on a shell.

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

    ...which I run in a shell.

    ...which I run from an xterm, which I spawn in the gui.

    Or, maybe, I run it in a browser.

    ...which I spawn from an icon in Gnome.

    I'm not seeing how this is a Good Thing.

  • Emacs does all this, or at least what I need from it, but without the weird interface. Or maybe with a weirder interface.

  • by Trailer Trash (60756) on Friday June 27, 2014 @07:46PM (#47337993) Homepage

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

    • by Chelloveck (14643)
      I can't be the only one who was mentally replacing "what if you could...?" with "why would I want to...?" and coming up dry most of the time.
  • by MacTO (1161105) on Friday June 27, 2014 @07:51PM (#47338027)

    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.

    • by Darinbob (1142669)

      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.

    • by trogdoro (3716731) on Friday June 27, 2014 @09:26PM (#47338445)
      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!
    • by Indigo (2453)

      MPW - that brings back some good memories. What a great development environment. Crunchy CLI-based power and scriptability wrapped in chewy GUI editing and ease-of-use. I miss using that every day.

  • I was pretty skeptical that this would just be a CLI superfluously decorated with GUI candy, but I ended up being pleasantly surprised. At the very least, this has potential.
  • The whole point of a shell is to not need the mouse. Keyboarding is inherently faster than mousing -- you're using 8 fingers, not one pointer -- especially if you're a touch typist.

    Being able to put your commands in a script for re-execution is an added bonus.

    • by msobkow (48369)

      The whole approach reminds me of a "graphical programming" tool for web interfaces that I used a few years back. While I was intrigued to try something new, I soon realized it was the slowest and clumsiest means of programming I had ever used, and just as prone to errors (though not syntax errors -- but those are but a small fraction of the mistakes programmers make, especially with any decent syntax highlighting editor.)

      • by dbIII (701233)

        I soon realized it was the slowest and clumsiest means of programming I had ever used

        I doubt it is as slow as LabView :(
        Never go full GUI.

        Once you go past anything that can be flowcharted on a single A4/letter sheet of paper you end up with lines crossing both over and under so it becomes a "write only" program that is not easily debugged and difficult for anyone other than the original writer/drawer to understand.

    • I remember asking a Mac user years ago why he loved his Mac so much and he said 'because of the keyboard shortcuts, I can work so much faster'.

  • Glad to see that things I was hearing about back in college, and used to experiment with Unix ports of in the early 90s, and which were also found in the pre-OSX Mac dev environment, are being reinvented as though they were new.

  • This reminds me of iPython notebook [ipython.org]. It allows to run/re-run python commands and display either text or graphics. You can also insert "formated comments", save a session, and share it. It's now reaching a good maturity, and is becoming a kind of "python" killer apps for scientists.

    As a side note, in addition to Python, it accepts shell commands, when preceding them with a !, to it could even replace a normal shell.

  • you don't have mouse support?
  • I like what Xiki is shooting for and look forward to trying it out. I have a similar interest in finding new ways to interact with a command shell. One such feature would be a shell and simple commands (in the Unix spirit) that natively work with URI resources rather than simply (local) file handles and sockets. My attempts to achieve this over the past 5 years has resulted in what I call IOVAR [iovar.com] (hosted on Google Code and iovar.com), a BASH-like shell for the web written in Java and currently running in Tomc

  • If you watch Doug's demo in its entirety, you can't help but see the similarities to this new project:

          http://www.1968demo.org/ [1968demo.org]

God may be subtle, but he isn't plain mean. -- Albert Einstein

Working...