unaccessability

[Alek Paunov]

On 17.11.2013 14:14, Nico Kadel-Garcia wrote:
> While this has been amusing, a lot of useful detail may be lost in the
> furor. There are some good philosophy questions about what GUI's
> should support for replacing command line tools (the gnome

...

>
> So step back, and let's think "how can we make this work for someone
> who hasn't seen it before and doesn't know how to hand-edit config
> files"?
>

My answer would be: With an lightweight web consoles.

Regular desktop users usually are scared by blank terminal window - They 
do not know what to type, also they are afraid that if they type 
something wrong and broke something then the severe sysadmin or the 
tech-y guy who was installed/supporting their system will be very angry :-)

But they are curious to try new things, especially when the new thing 
could bring them something cool (like e.g. simple loop to convert their 
incoming media).

The idea about the browser app, helping the users with command lines 
construction is not mine, I saw this in Cloud9 IDE (advanced browser 
based IDE, BTW, currently hosting user envs on OpenShift). They have 
command line at the bottom of IDE space, which exposes many of the IDE 
operations, offering code completion (visual equivalent of bash 
completion) for args filling + nice HTML (why not SVG) table results for 
(some of) the commands.

If this exposure of the command line tools looks acceptable for more 
wide range of users, we could:

  * choose "standard" for backend/webapp communication (e.g. 
NullMQ/MsgPack with these and these messages)
  * choose "standard" args grammar, for describing valid command lines
  * choose "standard" results grammar, for parsing the utility output 
streams
  * make a reference metadata for tool or two, which in addition to the 
grammars, have references to the relevant man page sections for the 
subcommands and thier args.

Given the e.g. above spec, the authors of current web based terminal 
emulators would be able to extend their projects, becoming funny and 
shiny command line composing (and why not simple snippets composing) 
tools and eventually package for Fedora.

On the other side we can offer to upstreams (or maintainers, where 
willing) to add this pure metadata, which should be positive for them in 
two ways:

  * possibly their tool becomes easy to use and accessible for wider 
audience.
  * most of the projects, will benefit of any pure metadata definition 
of their in/out grammars and documentation cross-references, because 
they do not have any.

I think, the Fedora as integrator of the half of the FLOSS software in 
the planet, with half of the Linuxes as downstreams is a good place for 
drafting such kind of standards.

After the standards acceptance, the remaining part is easy - we could 
reuse the comps, tags, requires/provides in the packages, etc, to 
generate the Big Fat Fedora tools catalog (the pallete of the web 
console) - When the user wants to try a tool she clicks, we yum 
installing the thing and system is ready to be blown by this curious 
user :-)

Kind Regards,
Alek