Linked by David Adams on Fri 5th Aug 2011 16:08 UTC
Graphics, User Interfaces A couple of days ago I read a blog post by Stephen Ramsay, a professor at the University of Nebraska-Lincoln and a Fellow at the Center for Digital Research in the Humanities. In it, he mentions that he has all but abandoned the GUI and finds the command line to be "faster, easier to understand, easier to integrate, more scalable, more portable, more sustainable, more consistent, and many, many times more flexible than even the most well-thought-out graphical apps." I found this very thought-provoking, because, like Ramsay, I spend a lot of time thinking about "The Future of Computing," and I think that the CLI, an interface from the past, might have a place in the interface of the future.
Thread beginning with comment 483866
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Two distinct beasts...
by WorknMan on Fri 5th Aug 2011 19:36 UTC in reply to "RE: Two distinct beasts..."
WorknMan
Member since:
2005-11-13

To the extent that GUI are inherently a superset of CLI, then in theory GUI should be every bit as good as CLI.


Well, GUI is not inherently a superset of CLI - it's a COMPANION. Meaning, each is better at some tasks than the other, so they go together like sugar and kool-aid, and I wouldn't be without either. Why must everything be turned into a pissing contest?

When it comes to GUIs, some have said how it's easier to pull up files in a CLI, like when you need to copy all files that are older than a certain date and with a certain extension. But what if you need to copy about 50 random files from a directory of 300 files that don't have any specific pattern to them? In that case, it's easy to CTRL+CLICK select the ones you need and drag them wherever. Similarly, the article mentions how it would be easier to manipulate music playlists, but what if you've got a playlist with 300 songs, and you want to custom sort them? Again, it's going to be easier to just drag stuff where you want them.

Of course, one could list dozens of examples were CLIs would be more useful... as I said before, it's not about which one is 'better', because that depends on the context.

However in practice GUI programs are incredibly difficult to automate.


Actually, no it isn't... at least on Windows, it's quite easy:

http://www.autoitscript.com/site/autoit

The only exception to this is if apps don't use standard widgets, which is one of about 486472343 reasons why I'm a fan of standards in this regard. Of course, on Linux, this would never work, since the general assumption seems to be that having 900 different toolkits is a good thing. So if GUI automation is hard, it's probably because of a piss-poor implementation, or someone hasn't written the tools to do it. But doesn't that work the same way on CLIs? I mean, SOMEONE has to build in pipes and stuff if you really want to do something useful with it ...

Reply Parent Score: 4

dragos.pop Member since:
2010-01-08

Of course, on Linux, this would never work, since the general assumption seems to be that having 900 different toolkits is a good thing. So if GUI automation is hard, it's probably because of a piss-poor implementation, or someone hasn't written the tools to do it. But doesn't that work the same way on CLIs? I mean, SOMEONE has to build in pipes and stuff if you really want to do something useful with it ...


Not necessary... it would work, but you have to chose the solution made for the toolkit that your app is build upon. Plus sending key and mouse events might work the same on all toolkits (but the recognition of widgets is not so portable).
Plus Qt offers an easy way to integrate scripting into your app (if it is open source or you are developing it).

Reply Parent Score: 1

benjymouse Member since:
2011-08-06

Actually, no it isn't... at least on Windows, it's quite easy:

http://www.autoitscript.com/site/autoit

The only exception to this is if apps don't use standard widgets, which is one of about 486472343 reasons why I'm a fan of standards in this regard.


Relying on widget types and -IDs for automation is inherently error prone and extremely brittle. I can never be more than a band-aid in the absence of a real automation framework.

All types of problems crop up: When suddenly an error message is displayed, when the dialog flow changes because of some unforeseen state, when timing issues crop up. Not to mention how enormously difficult it is to have robust error control in such an automated script. Or when a new version is released and IDs or widget types changes, when drop-down boxes doesn't contain the expected (and hard-wired) values. etc. etc.

Of course, on Linux, this would never work, since the general assumption seems to be that having 900 different toolkits is a good thing. So if GUI automation is hard, it's probably because of a piss-poor implementation, or someone hasn't written the tools to do it. But doesn't that work the same way on CLIs? I mean, SOMEONE has to build in pipes and stuff if you really want to do something useful with it ...


I wouldn't fault Linux for this. You were never supposed to rely on widget types and/or ID in the first place. The only ones who can reliably use those are the very developers of the apps who can use it for automated testing. The rest of us should stay away from it.

A much better solution is being developed with PowerShell. PowerShell "cmdlets" are suitable for sharing implementation with GUI application "command" patterns. Indeed this is what Exchange and several other MS server apps do now: They implement the cmdlets *first* and then build a GUI on top of those. The GUI then becomes the composition tool for PowerShell command pipelines.

The Exchange admin GUI will even show you the very PowerShell command pipeline it will execute and let use cut-and-paste it for automation.

PowerShell cmdlets are designed (unlike the typical *nix shell) for in-process execution, hence they can consume and produce strongly-typed in-process objects which makes it much more usable for actual GUI automation. In essense the GUI becomes a way to combine and design CLI commands.

Reply Parent Score: 1

WorknMan Member since:
2005-11-13

All types of problems crop up: When suddenly an error message is displayed, when the dialog flow changes because of some unforeseen state, when timing issues crop up.


I've never had an issue with timing when using controlsend to a certain widget/id. But, as you state, you may have to make some minor modifications if/when a new version is released and the developer changes things that directly affects your script, but wouldn't that be the case for CLI apps as well, if they change the command-line syntax?

Of course, GUI automation isn't the ideal way to get things done; I was just pointing out that it's not exceedingly difficult either, and certainly not impossible. In fact, I do it all the time ;)

Edited 2011-08-09 02:44 UTC

Reply Parent Score: 2