21 Apr
2011
21 Apr
'11
4:19 a.m.
On Wed, Apr 20, 2011 at 10:42:23PM +0200, Julien Claassen wrote:
Hello!
So I finally went through the thread and collected ideas and
thoughts. Here they are, a little chaotic still, but I suppose from
there we can go on, adding to it, shifting things.
Proposal for a good CLI access to audio (and other?) software
The interface should have two parts:
1. a shell-like commandline
2. an interactive fullscreen mode
Hi Julien,
I think you have some good ideas here. I just wanted to share a few
random thoughts...
Random thoughts:
* Use a tree structure for commands/parameters
* Have expand/collpase function for the parameter view (aptitude, mail-clients)
* Parameters are searchable (the tree-structure is searchable for node-data)
* Always move the real cursor (no soft cursor) to the actual parameter
* Encourage programmers to use consistent long and short commands for the shell part
* leave fullscreen mode by colon and enter by ESC
Questions:
* Which keys/mechanisms to use for collapse/expand?
* How to move between parameters on one level?
* What about real menus (as in file, view, edit,...)?
* Can one assume, that OSC is always the easiest/fastest choice and hardcode it?
* Would the commandline mainly just echo the fullscreen tree-structure?
* Would the commandline hold special (non fullscreen) commands?
I thought about a few of the questions and here are my tentative answers:
* Which keys/mechanisms to use for collapse/expand?
In alpine/pine the folder list (one major level of the tree) can
be navigated by using the cursor (all directions). ENTER is used to
access a folder (go down the tree). Only in the sublevels entries
(mails) are listed one underneath the other. So cursor left goes
back. Best to think of a different way, so one can have more
compressed layouts, probably organise strongly related parameters in
one row. For example Attack Decay Sustain and Release.
I've been using mutt, and I like to be able to navigate with one hand.
The 'j' and 'k' letters became fairly standard (because of vi)
to move up or down a page or list, and 'h' and 'l' for left and right.
To navigate down a hierarchy, I'm using 'i' (easily memorized as
'in'),
and to navigate back up again I use 'o' (easily memorized as 'out').
I find this quite intuïtive, and comfortable because you can relax the
other hand whilst navigating the hierarchy.
Of course, this is not really vi friendly, because 'i' and 'o' are
used to get to insert mode. But it mutt and newsbeuter it feels really
good.
* How to move between parameters on one level?
Well partly answered. I think simple lists (showsn as such) might
be very long seeing the amount of parameters Yoshimi has to offer.
Or what do you think? It is a little more complicated than aptitude
or some of the other examples, since they mostly use it for simple
lists or long menus.
* What about real menus (as in file, view, edit,...)?
I think some real menus might occasinally be nice. It's just
another tree with a root node, from which the main menus branch out.
Might be reached by something like Ctrl+first letter or a printed
capital.
* Can one assume, that OSC is always the easiest/fastest choice and
hardcode it?
* Would the commandline mainly just echo the fullscreen tree-structure?
If the command line does echo the full screen commands one might
use a filesystem like navigation: ls - show all parameters on this
level, probably with "/" after them, if they open a sublevel. cd
I think it would be great to have a generic command line interface
for controlling applications with OSC, that can be navigated as a
filesystem. I really like that idea, and it reminds me of the /proc
and /sys virtual filesystems that are used to set the kernel parameters.
Now I'm dreaming out loud, but would it be possible to automatically generate
such a filesystem, based on an OSC mapping.
Also I wonder if you would still need the tree view, because the output
of ls could provide you with something similar.
Well, I'm not sure this is the most realistic idea :-)
Greetings,
lieven