Linked by David Adams on Fri 5th Aug 2011 16:08 UTC
Thread beginning with comment 484286
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
More News »
Sponsored Links



Member since:
2011-08-06
The difference is that there is absolute no obligation on the developer to keep widget types and/or -id's stable across versions, much less behavior.
The developer of a CLI command has the option of introducing new parameters as non-breaking changes, or an entire new command if breaking changes are needed. That can keep the old command running.
More importantly, the developer of a CLI tool understands that she has an obligation to carefully avoid breaking changes as much as possible. Having some script depend on the tool is the *norm*. That is not the case with GUI keyboard/mouse-automation.
I have no doubt that it is possible (with some work). But as I pointed out it is not something you can build stable scripts (stable over time) upon. And the scripts tend to be horrible and have very poor error handling.