Slashdot Mirror
Open Source Macro Programs?
BlueCup asks: "I've wanted to switch to Linux for quite a while, but my work requires a lot of automated tasks. For these tasks I have global macros set up using Toolsworks and Macro Express. So far I've looked for equivalents for Linux, but have been unsuccessful. Does anyone know of a similar program that reaches the same level of complexity of the above programs for Linux?"
ah silly me. he wanted powerful configurable hot buttons(call them what you want)..
.
world was created 5 seconds before this post as it is.
These in-between macro systems have always struck me as eventually pretty rendundant and/or useless. At first most started as fairly simple GUI automation gadgets, sending window messages to this or that window, etc. Then they started adding some simple expression evaluation to make them a bit more robust, and eventually they ended up with a pretty much full-blown scripting language. Except that they are quite proprietary and still require a fairly steep learning curve. It begs the question why one wouldn't simply choose a general purpose interpreted language like Python that is truly cross-platform, is very expressive, and has very strong GUI bindings? I think the difference between learning the macro language of one of these proprietary thingies and learning something like Python is fairly minimal, and the advantage with learning Python is that you will know an established programming language that implements modern language concepts, not someone's idea of what a scripting subsystem needs.
If you can work with all your tasks and files and data on the command line, then you can just put your commands in a batch file. This was common under DOS. That is why the DOS people you talk to who really get things done are so into their ancient collections of small command line utilities, and usually don't use big monolithic programs that are supposed to have everything available from menus. Even in the DOS days the keyboard and mouse macro utilities were becoming popular because not everyone had a complete enough collection of those simple utilities.
When you use a mouse-and-menu interface, you are using the computer at a pre-language level. You are like a caveman who can't say "move the dead deer next to the fire" and instead you point and say "Ugh . . . duh!". This is fine if you are dealing with one task, but if you want to teach your cave child that deer should be put next to fire to cook it, you need language.
When you use graphical macro packages, you are like a caveman trying to make up for having no language by using a video camera and VCR. You video tape yourself saying "Ugh . . . duh!" one time and press rewind whenever you bring home another deer.
This is not to say you should try to be some console-only using elite unix jerk off. The graphical interface with it's multiple windows and desktops is a good way to keep track of the way people work on lots of things at once, from interruption to interruption and missed deadline to emergency. You can take the complecated tasks you script, and easily associate those commands with an icon on your desktop. But if you always run one icon and then run another, don't script the pre-linguistic pointing, take the underlying commands that those icons run, and put them in a new script, and make an icon for that.
The popularity of mouse-macro packages in Windows and Macintosh merely reflects that many of the people doing fairly complecated tasks on those systems don't know how to "talk" to their computers, they just know how to grunt and point. They'd rather pay for a new software package to help them grunt and point at collections of grunts and points rather than learn language.
So pick something reasonable and learn to work with language and collect your commands into scripts. The three obvious choices -- bash, perl, and elisp -- are all available on Windows, so you can be assured that your new skills will also be useful there.
There are any number of scripting languages which work well at the top level. Fewer work well as an "embedded" language. Three which fall into that category are Tcl, REXX and AppleScript. (Someone else mentioned DCOP.) Of those, Tcl is libre. There's probably a libre version of REXX floating around somewhere, but it doesn't matter too much. I would pick Tcl. Take a look at how DFS and Expect have embedded Tcl. Expect can also use Perl, but Perl isn't quite as seamless in that space.
AppleScript, although not free, is interesting for two reasons. (1) It uses Open Scripting Architecture, which separates the language syntax from the execution engine. (2) It has been used from the start for scripting GUI-like interactions, which is the kind of "macro" language which the original poster had in mind.