Re: [Dng] OT: separate GUI from commands
On Sun, May 31, 2015 at 12:19:51PM -0400, Hendrik Boom wrote: On Thu, May 28, 2015 at 07:16:55PM -0700, Isaac Dunham wrote: On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote: On 27/05/2015 12:12, Hendrik Boom wrote: I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? Maybe I'm misunderstanding the question, as I'm unfamiliar with the internal of editors. But IIUC, an editor is, by definition, a user interface, so the command-line / UI separation looks impossible or irrelevant to me here. However, there are still some separations that you can perform when designing an editor. Right off the top of my head: - Core functions vs. actual interface, which could be terminal-based or X-based. Think vim vs. gvim, or emacs -nw. - programmable editor commands vs. interface to enter those commands. Think the sed engine in vi, or the LISP engine in emacs. If you factor your work correctly, it should be trivial for a program to get access to your editor commands via a library function call - and you can make a command-line tool to wrap useful calls. Also, there could nvi (the Berkeley rewrite of vi, after abandoning their first version) uses a shared backend (vi-ipc) connected to the frontend via pipe(). There are about four frontends: terminfo-based (curses was derived from the code for this), tk, motif, and gtk. I ended up finding out this as a result of making the motif frontend build/work again. Thanks. I should probably look into that. It might be illumination. Which version of the code or inteernal documentation should I be looking for? And where? I think what I used was http://repo.or.cz/w/nvi.git, and the vi-ipc code is in ipc/. However, I'm not seeing much of anything by way of documentation. HTH, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
Le 31/05/2015 22:34, Laurent Bercot a écrit : On 31/05/2015 18:35, Didier Kryn wrote: AFAIU, this thread has turned to be about interfacing whatever app to a scripting language. I consider this a very usefull feature for all but basic applications. In particular, I consider that interfacing init - The init program which is pid 1 - with a scripting language would provide ultimate init freedom. init is the pinnacle of a basic application. It's not even an application, it's a system program. There is NO reason why you'd want to interface init to a scripting language - what are you trying to accomplish that can't be accomplished outside of process 1 ? init freedom, whatever that means, is a political goal, and has to be reached with political tools. Trying to use technical tools to reach a political goal is not a good idea; it usually produces bad software and ends up being unsatisfying for everyone. Laurent, I know the argument that init should be kept small to be rock-solid. Does it mean that it must be written in C and not in Lua or Ash? Anyway Sysvinit is not so small, invokes a great deal of shell scripts to do the job, and leaves service supervision to the admin. Please take it easy. I'm not saying this would be the fastest or the most secure of all init programs. But it would be a base for experimentation and hacking and I think it would be pretty educative. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Mon, 01 Jun 2015 11:25:03 +0200 Didier Kryn k...@in2p3.fr wrote: Laurent, I know the argument that init should be kept small to be rock-solid. Does it mean that it must be written in C and not in Lua or Ash? Yes. In my opinion it does. Init must be tiny, and it must be rock solid. Lua is written in C, so it adds more stuff than a pure C implementation. Anyway Sysvinit is not so small, invokes a great deal of shell scripts to do the job, and leaves service supervision to the admin. :-) A great many evils have been perpetrated based on being better than Sysvinit. In a few days, I will attempt to install an 89 line init (Suckless Init), on Plop C. Now *that's* small, although to compare apples with apples you must add daemontools-encore to the 89 lines, because Suckless Init does no process management, so that all must be done by daemontools-encore. And Laurent would probably point out that what I'll be attempting has PID1 single-time running its /etc/rc script instead of respawning it, so it's not appropriate for a real distro. But anyway, Sysvinit should never be used as a justification for anything. Please take it easy. I'm not saying this would be the fastest or the most secure of all init programs. But it would be a base for experimentation and hacking and I think it would be pretty educative. Now that you're talking about experimentation, you're talking *my* language. If it's just for experimentation, yeah, write it in Lua, write it in bash, split it into start/reap signals and process management. Rewriting daemontools in Lua --- that would be interesting. I personally think daemontools is more a philosophy than an implementation. LOL, imagine writing startup scripts in Lua. How cool would that be? But once again, this is for experimentation only. My official position on real work type computers is to do it with Epoch, runit, s6, or secondarily with Sysvinit + Daemontools or Sysvinit + OpenRC. One more thing. Your mileage may differ, but I've found it an order of magnitude easier to lay down Epoch or runit on a no-systemd distro than on a poetterized distro. So Devuan is the perfect host for *the individual user* to decide to jumper in Epoch, runit, or s6. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
Le 01/06/2015 12:59, Laurent Bercot a écrit : Oh, sure - I'm all for learning by experimenting and hacking away. It's just that this mailing-list is about a distribution that aims to be Debian-sized, so I thought you were suggesting it for Devuan. I think you'll agree that on a distribution, stability, not grounds for experimentation, is the primary concern. Yes, but the whole thread is off-topic :-) And this is not a project, only a dream. (PM: I tried to send you an e-mail and the in2p3.fr MX rejected it, for unknown reasons, and the postmaster isn't answering me. Do you have another e-mail address I could write you to ?) Strange. I know the server is strict about whatever conformance of the mail format and address of the sender to whatever existing standard, as a non-intrusive means to reject part of the spam. So maybe there is something unexpected from your mail agent. You can also reach me at didier.k...@free.fr or k...@lngs.infn.it. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Sun, May 31, 2015 at 01:54:50PM +, Arnt Gulbrandsen wrote: If I may... If you google me you will find old old reasons to hate me, and those reasons are connected to GUIs. I do know one or two thinks about the subject. It is possible to make a good GUI that is separated from its functionality in the manner many contributors to this thread are thinking of. But it has a touch of RFC1925 compliance: Pigs fly just fine, given sufficient thrust. Committees like to design such things, implementing them is hard work. An example may make it clearer: You have all seen disabled menu items. Those often correspond to CLI switches that lead to error messages in a given situation. But there is a difference: using the CLI switched lead to an error message when the user issues a command, while the menu items have to be disabled before the user issues the command. A GUI generally needs much closer contact with the object it manipulates before it issues a command than a CLI does. The CLI needs better error error reporting for actions that fail, the GUI needs much more information ahead of time... if it is to be good. There are other differences as well, e.g. good GUIs divide complex operations up into simpler ones in a manner that does not quite resemble good CLIs. Yes, clearly the interface that a GUI uses needs to be designed to facilitate interaction. But it us probaby a mistake to design it along the lines of one command = one mouse click. You'd want this programmatic interface to have the data gathering and imperative tools that any decent API would have. How to present this to the user and interpret her intentions is the proper domain of user-interface design. Making sure that the information needed is accessible is the proper domain for API design. The two are different. -- hendrik Writing sucky code is easy. But who wants to do that. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
AFAIU, this thread has turned to be about interfacing whatever app to a scripting language. I consider this a very usefull feature for all but basic applications. In particular, I consider that interfacing init - The init program which is pid 1 - with a scripting language would provide ultimate init freedom. There are few things the shell cannot do well enough to be a good init program; but I don't think it is possible to interface an application with the shell, I mean let the shell execute commands belonging to the application without forking a process. To come back to the list of scripting languages, I remember one very nice feature of Lua: AFAIR it has built in multitasking primitives. Another language was designed precisely to be interfaced to applications: Tcl. With Tk, it also involves the toolbox to make a GUI. My two cents. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Sun, 31 May 2015 08:51:58 -0400 Hendrik Boom hend...@topoi.pooq.com wrote: On Thu, May 28, 2015 at 11:58:55PM -0400, Jude Nelson wrote: (II) Lua Lua is also popular as a scripting language. I believe it was *designed* as a scripting language. I already mentioned that I'd prefer each application have its own Domain Specific Language (DSL) as its core, rather than an actual programming language. That has not changed, but let me tell you my opinion of Lua: Lua is IMHO the best all-around computer language in existance. With its all complex data represented by tables philosophy, it's conceptually simple and easy to learn and code. Its first class function philosophy makes binding data and algorithm together easy, without the artificial constraints of OOP. Its easy to implement closures make some pretty complex stuff easy. Every human on earth should learn Lua. Learning Lua is like taking a Data Structures and Algorithms class. All this stuff that you used to read about, that you just couldn't quite understand, pops into place once you learn Lua. The only reason I use Python instead of Lua is that Python comes with tried and true and tested addons such that you know if you start it in Python, you'll finish it in Python. Lua addons haven't reached that level of ubiquity and reliability, and having Lua addons do so isn't a priority for the project. Another thing. If you want to bind C to a scripting language back and forth, there's no better language than Lua. That was a major priority in Lua's design. Oh, and one more thing: Lua's faster than greased lightning, and if you want faster still, you can use its Just In Time facility, LuaJit. Here's some Lua info I've put together: http://troubleshooters.com/codecorn/lua/index.htm I vote for each app having its own non-Turing-complete DSL as its core. But if a Turing-Complete language *must* be selected, I can think of none better than Lua. By a long shot. SteveT Steve Litt May 2015 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On 31/05/2015 18:35, Didier Kryn wrote: AFAIU, this thread has turned to be about interfacing whatever app to a scripting language. I consider this a very usefull feature for all but basic applications. In particular, I consider that interfacing init - The init program which is pid 1 - with a scripting language would provide ultimate init freedom. init is the pinnacle of a basic application. It's not even an application, it's a system program. There is NO reason why you'd want to interface init to a scripting language - what are you trying to accomplish that can't be accomplished outside of process 1 ? init freedom, whatever that means, is a political goal, and has to be reached with political tools. Trying to use technical tools to reach a political goal is not a good idea; it usually produces bad software and ends up being unsatisfying for everyone. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Thu, May 28, 2015 at 07:16:55PM -0700, Isaac Dunham wrote: On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote: On 27/05/2015 12:12, Hendrik Boom wrote: I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? Maybe I'm misunderstanding the question, as I'm unfamiliar with the internal of editors. But IIUC, an editor is, by definition, a user interface, so the command-line / UI separation looks impossible or irrelevant to me here. However, there are still some separations that you can perform when designing an editor. Right off the top of my head: - Core functions vs. actual interface, which could be terminal-based or X-based. Think vim vs. gvim, or emacs -nw. - programmable editor commands vs. interface to enter those commands. Think the sed engine in vi, or the LISP engine in emacs. If you factor your work correctly, it should be trivial for a program to get access to your editor commands via a library function call - and you can make a command-line tool to wrap useful calls. Also, there could nvi (the Berkeley rewrite of vi, after abandoning their first version) uses a shared backend (vi-ipc) connected to the frontend via pipe(). There are about four frontends: terminfo-based (curses was derived from the code for this), tk, motif, and gtk. I ended up finding out this as a result of making the motif frontend build/work again. Thanks. I should probably look into that. It might be illumination. Which version of the code or inteernal documentation should I be looking for? And where? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
Am Donnerstag, 28. Mai 2015, 23:58:55 schrieb Jude Nelson: 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. In addition to that there are dbus interfaces of applications. But of course they only export a subset of state and functionality. That what the developer has implemented into the dbus API. And for KDE/Plasma/Qt there is QML / Qt Quick which is some kind of markup for the GUI and JavaScript or C++ for the logic behind it. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
If I may... If you google me you will find old old reasons to hate me, and those reasons are connected to GUIs. I do know one or two thinks about the subject. It is possible to make a good GUI that is separated from its functionality in the manner many contributors to this thread are thinking of. But it has a touch of RFC1925 compliance: Pigs fly just fine, given sufficient thrust. Committees like to design such things, implementing them is hard work. An example may make it clearer: You have all seen disabled menu items. Those often correspond to CLI switches that lead to error messages in a given situation. But there is a difference: using the CLI switched lead to an error message when the user issues a command, while the menu items have to be disabled before the user issues the command. A GUI generally needs much closer contact with the object it manipulates before it issues a command than a CLI does. The CLI needs better error error reporting for actions that fail, the GUI needs much more information ahead of time... if it is to be good. There are other differences as well, e.g. good GUIs divide complex operations up into simpler ones in a manner that does not quite resemble good CLIs. Writing sucky code is easy. But who wants to do that. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Thu, May 28, 2015 at 11:58:55PM -0400, 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? (I) Scheme The official scripting language for the GNU project seems to be Scheme, as implemented by 'guile'. I suspect other implementations could do as well. SOme of the modern Scheme inplementations actually compile to byte code or machine code during interpretation, makint it relatively efficient. I'm told it's the scripting language for the Gimp. It is the report generator in gnucash. In fact, gnucash was originally written in Scheme (I think in fact it was guile) with specific parts in C or C++. The current gnucash developers don't like Scheme much, and have pretty well eliminated it from most of the code. It still remains in the report generator. To the extend they are still using a scripting language, they're using python now. I think their reasons for avoiding Scheme are: (1) the interface between Scheme and the C/C++ code is undocumented, making it pretty well unusable, and (2) they don't like parentheses. Of course emacs is mostly implemented in its own dialect of Lisp, which serves as a scripting language as well, but (*big* defiency) does *not* do static binding of identifiers properly. (II) Lua Lua is also popular as a scripting language. I believe it was *designed* as a scripting language. The revision control system monotone uses lua for its user-coded plug-ins. Independent of this, it also has an 'automate' interface allowing monotone to be controled from another process, with a text interface piped biderectionally through Unix pipes. I don't know how this interface works on Windows. 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 :) Make it a library, so that the various language users can easily do their own bindings. Avoid needing pointers to data that's managed by the user's programming language so that garbage collection wont make everything go blooey when the data are moved. Especially avoid storing pointers to user data long-term. Of course, this may be unavoidable for some purposes (such as callbacks). -- hendrik * 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 :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
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 :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote: On 27/05/2015 12:12, Hendrik Boom wrote: I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? Maybe I'm misunderstanding the question, as I'm unfamiliar with the internal of editors. But IIUC, an editor is, by definition, a user interface, so the command-line / UI separation looks impossible or irrelevant to me here. However, there are still some separations that you can perform when designing an editor. Right off the top of my head: - Core functions vs. actual interface, which could be terminal-based or X-based. Think vim vs. gvim, or emacs -nw. - programmable editor commands vs. interface to enter those commands. Think the sed engine in vi, or the LISP engine in emacs. If you factor your work correctly, it should be trivial for a program to get access to your editor commands via a library function call - and you can make a command-line tool to wrap useful calls. Also, there could nvi (the Berkeley rewrite of vi, after abandoning their first version) uses a shared backend (vi-ipc) connected to the frontend via pipe(). There are about four frontends: terminfo-based (curses was derived from the code for this), tk, motif, and gtk. I ended up finding out this as a result of making the motif frontend build/work again. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
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 :) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote: As a rule of thumb, developers should always use the smallest possible amount of dependencies for a project, and clearly separate layers - e.g. if a project comes with an engine and a GUI, then the engine should come as a command-line tool in its own package with no dependencies on graphical stuff, which would be the role of the GUI package. But I'm a dinosaur AND a fan of minimalism, so I don't expect many people to think like me. I mean this as a serious question, not as a piece of sarcasm, though it could easily be misconstrued as such. I am testing the limits of the advice to separate interaction from command line, though. Sometimes limit testing leads to discoveries. I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? Brainstorming welcome. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi Hendrik, On Wed, May 27, 2015 at 6:12 AM, Hendrik Boom hend...@topoi.pooq.com wrote: On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote: As a rule of thumb, developers should always use the smallest possible amount of dependencies for a project, and clearly separate layers - e.g. if a project comes with an engine and a GUI, then the engine should come as a command-line tool in its own package with no dependencies on graphical stuff, which would be the role of the GUI package. But I'm a dinosaur AND a fan of minimalism, so I don't expect many people to think like me. I mean this as a serious question, not as a piece of sarcasm, though it could easily be misconstrued as such. I am testing the limits of the advice to separate interaction from command line, though. Sometimes limit testing leads to discoveries. I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? Brainstorming welcome. I've been thinking about the general form of this problem (and a general solution) for months, and I think I'm almost ready to provide a formal design document. [The Problem] Many programs couple the business logic to the presentation logic. The code that drives the UI is too intermingled with the code that provides the application's core functionality to use them separately, or develop on them independently. However, we would like to be able to do this in order to allow the user to apply existing tools and skills in one domain without affecting the other domain, and allow developers to innovate in one domain without affecting the other. This should be possible, since rendering a UI is usually (but not always) a separate, orthogonal concern from performing the desired functionality. [Motivation] I was watching my SO create a (long) Powerpoint presentation the other day, and she wanted to add a fade in animation to each bullet point on each slide. Powerpoint (and every office suite I'm familiar with) makes you do this by hand, bullet-point by bullet-point, with a mouse. The UNIX hacker in me saw this, and wondered why it's not possible to simply open a shell and run something like for ppt_bullet in $(ppt-ls bullets); do ppt-animate fade-in $ppt_bullet; done. This would have saved an hour of tedious, repetitive effort. The reason this isn't possible is because Powerpoint (and every other office suite) does not offer a command-oriented UI. What could Powerpoint have done? One option is to add a program-specific command-language (like how vim and emacs do). However, I don't think this the answer either, for two reasons: (1) The UI (the command-language in this case) is still tightly coupled to the program, and has rules and semantics that are only applicable to the program. (2) Without careful design, the user can't bring to bear existing knowledge or existing tools to address problems. This is a general gripe I have against vim and emacs too--if you're going to offer a Turing-complete command language, why not offer one that is widely-used already and lets people use external tools? What I would like the most is if Powerpoint were somehow designed so that its runtime state was exposed to the system shell, so I could operate on it directly. Powerpoint wouldn't need to ship with its own custom language, and I could use whatever tools I wanted. [Related Work] This is something that Smalltalk/SQUEAK got right, as well as SecondLife (but to a lesser extent). In these environments, a UI element is fully scriptable by the user, and can access functionality in other UI elements and store persistent state within them. As a user, I can easily add my own functional overlays on top of the application, as well as my own custom UIs that extend the functionality of the application on-the-fly. If Powerpoint were written as a SQUEAK application, I might have been able to write and attach a button on-the-fly that iterated through each bullet point and added an animation. This is something that RESTful Web services sometimes get right as well. The business logic in a RESTful Web service is meant to be decoupled from the CSS/HTML/Javascript UI, so you should be able to use use any HTTP-speaking client to interact with the business logic on the remote servers. For example, this lets Web front-end developers create mash-ups of multiple services, and it lets devops and back-end developers write scripts with curl to interact with services. The downside is that you're limited by the availability and expressiveness of the RESTful API (which you do not control). Applescript, ActiveScript, and nowadays Powershell try to do something like this, but they fall short architecturally in that they can't access and operate on all of the application's state (i.e. the
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
On Wed, May 27, 2015 at 06:12:15AM -0400, Hendrik Boom wrote: On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote: As a rule of thumb, developers should always use the smallest possible amount of dependencies for a project, and clearly separate layers - e.g. if a project comes with an engine and a GUI, then the engine should come as a command-line tool in its own package with no dependencies on graphical stuff, which would be the role of the GUI package. But I'm a dinosaur AND a fan of minimalism, so I don't expect many people to think like me. I mean this as a serious question, not as a piece of sarcasm, though it could easily be misconstrued as such. I am testing the limits of the advice to separate interaction from command line, though. Sometimes limit testing leads to discoveries. I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? It's a matter of building an editor like leafpad, or building a vi or an ed. What are you working on? If you're working on the latter, take vim, neovim and vis as examples: they do a lot more than writing in place, save, colorize and undo. Thus, decoupling the engine from the UI means that you have already on draft what does the editor do and how as for example as a list of commands. Then the UI, as a command line client, probably would behave like a shell script, or like ed or ex; as a full blown editor, no matter if curses or GUI, probably would grab commands (through modes or menus) and input, and synchronizes with the engine (which executes special commands, changes files, write to them, and whatever else). If everything is in the same process, this synchronization is mostly done as code execution; otherwise it's developed in a client-server model: the UI shows to the user her/his edits, while passing messages to the engine, for example sending text or msgpack through a socket read by clients (where the user types) and the editor engine. This aids mostly code reuse, because you could have any kind of GUI and the powerful set of commands you feel comfy about for editing text. -- Teodoro Santoni ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On 27/05/2015 12:12, Hendrik Boom wrote: I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? Maybe I'm misunderstanding the question, as I'm unfamiliar with the internal of editors. But IIUC, an editor is, by definition, a user interface, so the command-line / UI separation looks impossible or irrelevant to me here. However, there are still some separations that you can perform when designing an editor. Right off the top of my head: - Core functions vs. actual interface, which could be terminal-based or X-based. Think vim vs. gvim, or emacs -nw. - programmable editor commands vs. interface to enter those commands. Think the sed engine in vi, or the LISP engine in emacs. If you factor your work correctly, it should be trivial for a program to get access to your editor commands via a library function call - and you can make a command-line tool to wrap useful calls. Also, there could be an editor-base package with very few dependencies, providing your main library; and an editor-text package depending on editor-base and ncurses (for instance), and an editor-gui package depending on editor-base and your favorite graphical libraries. So text-only users wouldn't have to install editor-gui and pull the whole plate of spaghetti. My 2 cents, -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
Hi, Hendrik. Your post reminds me of a chapter in The Art of Unix Programming, by Eric Steven Raymond, which I always recommend. http://catb.org/~esr/writings/taoup/ El 2015-05-27 06:12, Hendrik Boom escribió: ... I am testing the limits of the advice to separate interaction from command line, though. Sometimes limit testing leads to discoveries. ... Brainstorming welcome. -- Saludos cordiales, Ángel Ramírez Isea. Usuario de Devuan y Canaima GNU / Linux # 460737. Coordinador General. Cooperativa Simón Rodríguez para el Conocimiento Libre, RS. www.simonrodriguez.org.ve (261) 524.55.93 -:- (426) 369.57.18 J-40294137-4 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands
On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote: On 27/05/2015 12:12, Hendrik Boom wrote: I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? Maybe I'm misunderstanding the question, as I'm unfamiliar with the internal of editors. But IIUC, an editor is, by definition, a user interface, so the command-line / UI separation looks impossible or irrelevant to me here. From your reply, I conclude you understood exactly what I meant. Thank you. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
On Wed, May 27, 2015 at 02:27:17PM -0400, Jude Nelson wrote: Hi Hendrik, ... (much snipped) (I'm sorry, I hadn't meant to take you away from vdev for the amount of time it took to write this lengthy and interesting reply) An interesting consequence of structuring applications this way is that you can trivially solve both network transparency and application distribution: simply put the application on an NFS mount (or some network filesystem), and run the interpreter on the local client. The application stores runtime state as files within its directory hierarchy, so they get automatically written to the NFS server. Users could run remote applications locally simply by mounting the remote volume and running the interpreter on them in-place. I was considering building such an interpreter as well as and a suite of applications for Devuan at some point, after finishing vdev. I was thinking of calling it shui--both from the concept of feng shui (the idea of harmonizing everyone with their environment), as well as serving as an acronym for SHell-oriented User Interface. Sounds interesting. But for applications like ordinary text editing, it might become a little slow if you end up running a shell script with every character typed. The idea did seem to work somewhat for the ancient mail handler MH (if I recall correctly). But as for the file system ... I wonder if the completely virtual file system in something like Inferno could help things along -- put more of the primitive operations into the file itself. Or have I misunderstood Inferno? Of course, taking this to its logical conclusion would move the file system rather seriously in the direction of a typed persistent objects system, with methods and so forth. A very different beast from what we're used to. -- hendrik -Jude ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: separate GUI from commands (was: Re: The more things change, the more they remain the same
On Wed, 27 May 2015 14:27:17 -0400 Jude Nelson jud...@gmail.com wrote: I've been thinking about the general form of this problem (and a general solution) for months, and I think I'm almost ready to provide a formal design document. [The Problem] Many programs couple the business logic to the presentation logic. The code that drives the UI is too intermingled with the code that provides the application's core functionality to use them separately, or develop on them independently. Hi Jude, Be careful what you wish for. MVC was created to solve this problem, and it looks to me like, in the hands of most developers, like MVC makes an unfathomable Easter Egg Hunt where a reasonably simple algorithm can't go six lines without the need to go look something up somewhere else. And yet, in the hands of most practitioners, my observation is they *still* manage to intersperse program logic, data and UI. Separation is good, but not all ideas for separation are good. [clip] [Motivation] I was watching my SO create a (long) Powerpoint presentation the other day, and she wanted to add a fade in animation to each bullet point on each slide. Powerpoint (and every office suite I'm familiar with) makes you do this by hand, bullet-point by bullet-point, with a mouse. The UNIX hacker in me saw this, and wondered why it's not possible to simply open a shell and run something like for ppt_bullet in $(ppt-ls bullets); do ppt-animate fade-in $ppt_bullet; done. This would have saved an hour of tedious, repetitive effort. The reason this isn't possible is because Powerpoint (and every other office suite) does not offer a command-oriented UI. What could Powerpoint have done? One option is to add a program-specific command-language (like how vim and emacs do). However, I don't think this the answer either, for two reasons: (1) The UI (the command-language in this case) is still tightly coupled to the program, and has rules and semantics that are only applicable to the program. I think #1 above is a *good* thing. There's a reason it's called a *domain* specific language. It's the functions of this program's business logic, and nothing more. (2) Without careful design, the user can't bring to bear existing knowledge or existing tools to address problems. This is a general gripe I have against vim and emacs too--if you're going to offer a Turing-complete command language, why not offer one that is widely-used already and lets people use external tools? That's just it. I think packaging a Turning-complete language is overkill, much the same as having the init system take charge of login logic. I'm an elder in the Church of the Parsimoneous Scope. I'd prefer to expose every business logic function, such that it's callable from the command prompt and other places. Those functions are the thin interface connecting business logic and appearance. There's nothing Turing complete about them. If you want Turing completedness, that's for the program Years ago GoLUG's Gary Miller told me something I never forgot. When writing a program, he makes his entire user interface as input and output to a socket. That way, on his side of the socket, there's no need for Python-Tk, nor Curses, nor GTk nor tk nor HTML generation nor mod-apache-whatever: None of that complication. Nothing but business logic algorithms and the functions that implement them. Write it in simple, no-dependency C, Python, Perl, Ruby, Lua, whatever. Then Gary publicizes the commands that socket takes, so the other guy can write a program with Curses or Python-Tk or whatever, to present the info to the user, as needed. This presentation program has all the GUI molassas, but no business logic, so it's pretty straightforward. And you have complete separation of business logic from presentation, enforced by a socket. But of course, the thing on the far side of the socket can be more than a UI. It can be a script. It can be a program that turns a config file into a script. It can be a command prompt (using telnet) to tweak. You can accomplish almost anything, except adding a function or changing a function's actions on Gary's side of the program. If you want to do that, do it on Gary's side. What I would like the most is if Powerpoint were somehow designed so that its runtime state was exposed to the system shell, so I could operate on it directly. Powerpoint wouldn't need to ship with its own custom language, and I could use whatever tools I wanted. I'm pretty sure Gary's method would do just that. [snip] [Design Notes] The idea I I'm working on can be thought of as a re-telling of the SQUEAK story for the UNIX environment: * The shell is the binding language between different aspects of the application, as well as between the application and external tools (this replaces Smalltalk). * Persistent state is encoded as files As a djb enthusiast, I'm always happy when state is encoded as files and directories. *
Re: [Dng] OT: separate GUI from commands
On 05/27/2015 02:27 PM, Jude Nelson wrote: Hi Hendrik, On Wed, May 27, 2015 at 6:12 AM, Hendrik Boom hend...@topoi.pooq.com mailto:hend...@topoi.pooq.com wrote: On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote: As a rule of thumb, developers should always use the smallest possible amount of dependencies for a project, and clearly separate layers - e.g. if a project comes with an engine and a GUI, then the engine should come as a command-line tool in its own package with no dependencies on graphical stuff, which would be the role of the GUI package. But I'm a dinosaur AND a fan of minimalism, so I don't expect many people to think like me. I mean this as a serious question, not as a piece of sarcasm, though it could easily be misconstrued as such. I am testing the limits of the advice to separate interaction from command line, though. Sometimes limit testing leads to discoveries. I'm in the process of writing (yet) a(nother) editor and output formatter, and on reading this, I started to wonder -- just how could one separate a command-line version from the UI? I can see that the output formatter can be so separated (and very usefully), but the actual editing? Brainstorming welcome. I've been thinking about the general form of this problem (and a general solution) for months, and I think I'm almost ready to provide a formal design document. [The Problem] Many programs couple the business logic to the presentation logic. The code that drives the UI is too intermingled with the code that provides the application's core functionality to use them separately, or develop on them independently. However, we would like to be able to do this in order to allow the user to apply existing tools and skills in one domain without affecting the other domain, and allow developers to innovate in one domain without affecting the other. This should be possible, since rendering a UI is usually (but not always) a separate, orthogonal concern from performing the desired functionality. [Motivation] I was watching my SO create a (long) Powerpoint presentation the other day, and she wanted to add a fade in animation to each bullet point on each slide. Powerpoint (and every office suite I'm familiar with) makes you do this by hand, bullet-point by bullet-point, with a mouse. The UNIX hacker in me saw this, and wondered why it's not possible to simply open a shell and run something like for ppt_bullet in $(ppt-ls bullets); do ppt-animate fade-in $ppt_bullet; done. This would have saved an hour of tedious, repetitive effort. 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.) * 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. Just imagine the possibilities if Powerpoint gave you access to an environment like that! -Jonathan a20379251c47f4b0322b70d1069ab8ba66499228a7c92dccb1fdf7b99a3e77f2 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
