Hi Jonathan,

>
> 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
>
>
Haha, good one!


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

Not necessarily. See below.


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

Funny you bring up GNOME as a related example. A few GNOME developers on
Twitter just spent the last few days hating on the very idea of a
scriptable UI (and the Devuan community in general), all in response to
this very email thread.


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

The design is still pretty rough in my head (I brought it up because it was
related to Hendrik's original post, and it seemed like a good time to get
feedback), but I don't think shui needs to have the same design as a Web
browser. It wouldn't track nearly as much information, for example. All
it would need to do is render the application's UI and run helper programs
as subprocesses to handle UI events. It's not a perfect fit for every
graphical application, but my goal would be to make it easier to make
applications whose behaviors can be systemically extended and automated by
the user.

Thanks,
Jude