3 ms·

My theory on this is that GUI automation is way harder because most solutions requires the developer to explicitly spend more time on implementing something tha

My theory on this is that GUI automation is way harder because most solutions requires the developer to explicitly spend more time on implementing something that is not usually useful to sales (non-automatable applications are the norm, and people don't decide to buy apps based on whether it supports automation or not). CLIs are much easier because the primary interface (standard out) to communicate with the user is basically the automation API (whether it is stable or not). If you're a command line program, (unless you're doing something super wary), you're automatable. My personal opinion is that the best way should support automating based on GUI interfaces… although I don't have any great ideas how to support various interfaces that are e.g. modal or contextual. The clipboard is basically poor man's pipes in the GUI world so we could take some ideas on how the clipboard and the source/destination application negotiate data types, and there probably are better ideas.

pksebben 5y ago
I've always thought that the Unix philosophy could do well here; if you start by building the rawest version of your app to operate on the command line, and then make the UI an interface to that, you can trivially automate anything the UI can do. so in this scheme, the cli's "do one thing and do it well" is driving the program, while the UI's "one thing" is providing an interface to the cli. the other nice thing about this is that it provides a far more debuggable build. also enforces good habits vis a vis separating abstractions. not always possible in all contexts, though. I would have trouble implementing this for an app like Photoshop (although their command palette implementation is super close)
- sobkas 5y ago
  > I've always thought that the Unix philosophy could do well here; if you start by building the rawest version of your app to operate on the command line, and then make the UI an interface to that, you can trivially automate anything the UI can do. That why open source software have the best UIs. /s

pksebben 5y ago

I've always thought that the Unix philosophy could do well here; if you start by building the rawest version of your app to operate on the command line, and then make the UI an interface to that, you can trivially automate anything the UI can do. so in this scheme, the cli's "do one thing and do it well" is driving the program, while the UI's "one thing" is providing an interface to the cli. the other nice thing about this is that it provides a far more debuggable build. also enforces good habits vis a vis separating abstractions. not always possible in all contexts, though. I would have trouble implementing this for an app like Photoshop (although their command palette implementation is super close)

sobkas 5y ago
> I've always thought that the Unix philosophy could do well here; if you start by building the rawest version of your app to operate on the command line, and then make the UI an interface to that, you can trivially automate anything the UI can do. That why open source software have the best UIs. /s