:: Re: [Dng] OT: separate GUI from com…
Top Page
Delete this message
Reply to this message
Author: Jonathan Wilkes
Date:  
To: Jude Nelson
CC: dng@lists.dyne.org
Subject: Re: [Dng] OT: separate GUI from commands
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