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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
