:: Re: [Dng] OT: separate GUI from com…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Jude Nelson
Fecha:  
A: Jonathan Wilkes
Cc: dng@lists.dyne.org
Asunto: Re: [Dng] OT: separate GUI from commands
Hi Jonathan,

Shell-based command access to software like Powerpoint would indeed be
> great. But I wonder if we can raise the bar a bit
> and consider an approach that could serve the largest audience.
> Especially users who themselves aren't developers or
> programmers.
>
> It seems to me such a system must be characterized by the following two
> properties:
> * basic - the language itself should be simple enough that the user
> doesn't have to spend too much time on boilerplate and
> learning eccentricities of the language. (And the environment should be
> able to generate as much of the boilerplate on its own,
> especially for common patterns.)
>


What language would you propose? If I create shui, I'd make it
language-agnostic so users can select whatever language(s) they want. My
example with shell scripts was just to illustrate the possibility :)


> * visual - we know the user is already interacting with a graphical
> system. So it makes sense that the command-based
> system should include graphical modes of interaction and visualize as much
> as it can. (For example, letting the user choose
> from a set of familiar widgets rather than making them memorize a baroque
> naming system.) It should look as familiar as it
> can without sacrificing power, letting the user see as much of the data
> flow without having to create the entire mental model
> on their own.
>


Yeah, a RAD tool would be a natural extension of the idea!


> Just imagine the possibilities if Powerpoint gave you access to an
> environment like that!
>


It didn't occur to me when I wrote my original email, but it turns out
Powerpoint can be scripted with VBA. So can Libreoffice (it supports
Javascript and Python as well as Libreoffice Basic). There are others,
like Blender, GIMP, KDE (i.e. SuperKaramba, Plasma, Kross), GNOME 3, the
NetBSD kernel (Lua), the Linux kernel (ePBF), and so on, that I had
forgotten to list.

If anything, I think it validates the case for a system like shui. The
fact that different applications in different problem domains independently
gain built-in support for scripting suggests that there's a
naturally-occurring need to be able to interact with applications
programmatically as well as interactively. So, why not design applications
with this need in mind from the get-go?

-Jude

PS Not sure why, but your email hit my (Gmail's) spam filter. Just
thought you should know :)