On 05/28/2015 11:58 PM, Jude Nelson wrote:
> 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.

Yes I know, I was trolling. But it was a friendly troll. See, I
included a hash at the end of my email. Here is my Proof-of-Troll(tm)
that matches that hash:

echo "Sorry but I couldn't resist trolling you here. :) Still intrigued
by your file-system based widget idea, though." | sha256sum

In retrospect I should have been more detailed that the troll was
playing dumb about Visual Basic, but if you switch the order
of my two categories you can see the strong evidence. :)

>
> 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?

I think because you would need to have all the applications use the same
language.

For example, if I use the 'lg' console in Gnome Shell (which is
essentially just a poor man's HTML5 devtools) I can get access
to javascript objects that represent the various elements of the DE.
But when I say 'element' I only mean the x11 windows
and the pre-fabbed Gnome widgets and stuff. For example, I can't
inspect the "Save" button in Thunderbird and change its
attribute "display" to "none". That makes 'lg' so limited that I can
safely say I've never used it in all the time I've used Gnome.

I use the devtools in Chrome and Firefox all the time, however. I do
this because most of the time I can inspect every element
that makes up the web page or app I happen to be viewing. (I can also
get FPS, profile, and all kinds of other invaluable
instant feedback.) Exceptions are of course webgl and HTML5 canvas
(because those contents are just pixels), but I don't run into those so
often in my normal browsing.

This is already slow with all apps on the web (well, most) using the
same language (and being optimized on the fly on modern
browsers). Seems like for this to be workable on the desktop you'd need
wrappers for various languages which would add even more overhead.

But it's quite possible I've misunderstood the upshot of the system
you're describing.

-Jonathan

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