On 05/31/2015 05:01 AM, Jude Nelson wrote:
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.
I'd highly suggest looking at Qt and QML for inspiration. One of their key goals seems to be lowering the cost of developing UIs. It's a supportive community chock full of documentation so you should be able to quickly get a sense of their approach.
-Jonathan
Thanks, Jude
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
