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?"
I'm glad this question was asked, as I am trying to do something that would greatly benefit from a macro...
Converting PowerPoint presentations from PPT to SWF is something that OpenOffice seems to do very well. The research group that I am involved with at BGSU has developed a video-conferencing tool in Flash. We'd like to embed PPT's into the video conferences, but as of now we have to convert each frame by hand, then make the SWF in flash, a very tedious process...
Any ideas on how to script Open Office to convert PPTs to SWF's?
Cloud City Digital: DVD Production at its cheapest/finest
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.
The command line tools are great for "macros" (scripting). Truthfully, I don't really know any graphical programs on linux that I'd want to script. So, emacs works great for me there---but I guess I deal mostly with text.
I dont think anyone can fairly answer your question without some specifics about why you would want to switch to Linux. I mean, I'm guessing "I love the command-line!" isnt high on the list.
This comment may never be seen, it depends on if it's seen first by the "He hates linux! Get him!" mods or the "He didnt jump to supporting various open-source projects, I have no idea what he's saying but it's probably insightful!" mods..
If this is the kind of tool you are used to using, I dont think Linux is the right solution for your "automated tasks". I guess that's just my opinion, but people who are used to using "Macros" which act like a user instead of "Scripts" which do their best to get the job done and tend not to be friendly to programs which dont know about them, I don't think they're ready for linux.
This isnt a "Linux isnt ready for them", thing, it just seems to me that Linux is a different way of thinking, seperate from these "Automating a task means having the computer repeat you" macro programs. (Yes, it's a simplification, but since the guy is talking about "Using these programs" instead of "programming in VBA", I'm guessing he's having the programs do most of the work for him)
Explain what it is that attracts you to linux, and you're likely to get an answer which comes closer to what you really want.
That said, check out "Expect" here
-- 'The' Lord and Master Bitman On High, Master Of All
Well, not exactly, but I think that you will find that many tools which evolved within UNIX culture (not necessarily only on Linux) have much higher degree of built-in scriptability.
;-)
In addition to pretty (or not so pretty) GUIs, their designers felt obliged to incorporate an alternative text-based interface, not to mention that many useful packages started from being text-based and grew their GUI skins later on. In any case, most often everything that you can do with keyboard and mouse (and then some) can be done via some kind of command line.
Gimp and OpenOffice.org are good examples of build-in scriptability, and, of course, EMACS Rulez!!!
Of course if no single program can do everything that you need you can tie programs together either by generating scripts (in, e.g., Perl) and calling the progams from within a perl script, or using the built-in language of whatever main tool you are using and calling arbitrary scripts and programs using its system() facility.
Hope this helps.
Paul B.
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.
New KDE contains some pretty nifty hot-key action editor (in control center), take a look, you might find it's what you are looking for.
"macros" usually have to do with scripting GUI apps, yet another thing Linux mostly blows at, especially compared to AppleScript/OSA on Mac OS X but even Windows' WSH is better. There is KDE's and Qt's DCOP system, which is neat but very poorly supported.
There are a lot of things you can't do with bash or perl. The unix mindset would be to simply rewrite the whole app that they want to automate's functionality all over again in bash, perl or C, and then control that app with perl/bash/whatever. But that is a royal pain in the ass.
I don't think the poster would care if the particular macro package happened to be a perl module that added the ability to write automation macros for X apps, but if such a thing existed, it would be worth naming.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I get the impression that you want to record mouse movements and keystrokes and whatnot, but given that I don't know the specific tasks that you are trying to "macro" I think this method of automation is bass-ackwards.
I can't think of very many tasks in linux that cannot be done with console based alternatives to graphical ones. That being the case, you can control and automate all aspects of a console application using bash or the shell of your choice.
But if you must automate an application that only has a graphical interface, this application should do it.
In the Linux/UNIX world, we call "macros" scripts. They do automated tasks, just like macros do, and most of the time more efficient than their Windows counterparts. Expect is an excellent utility for creating "macros", in addition to the capabilities of Perl, etc, Expect allows you to redirect output and input better, in a more "friendly" way.
Bored? Why not join a decent mess
Remote Control and Scripting of Gnome Applications with Python. It should also work for KDE and Java apps once they get their act together.
It's here today, and it works. I was at the talk at LCA this year. Write a Python script, add a launcher for it on your panel/desktop, and away you go!
-mike
-- "So, what's the deal with Auntie Gerschwitz et all?"
m4
Gates' Law: Every 18 months, the speed of software halves.
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.
Perl isn't called a "glue language" for no reason. You can stick *anything*
together with it. Need to process an image using Gimp's filters, resize it,
and insert it into an OpenOffice document? No problem, Perl can do that.
(You need the Gimp/Perl bindings, which most distros make a separate package
from the Gimp itself, but installing them easy. If you want the script to
be portable at all, you also want Archive::Zip. If portability doesn't
matter you can backtick out to the info-zip version of zip instead.) Need to
automatically retrieve a webpage, fill out and submit a series of forms, parse
the resulting page, extract some data, and insert that into the document too?
No problem. (You want WWW::Mechanize and HTML::Tree.) I could go on, but you
get the idea. When it comes to automating common repetitive tasks, Perl is
awesome, and the modules on the CPAN have most of the work already done.
If all you want is to press a key on the keyboard and have a series of key
strokes punched in, get yourself a macro-equipped keyboard. (Avant makes the
top-of-the-line ones, but there are cheaper ones out there too.) But if you
want to make things happen automatically while you sleep, read slashdot, and
do other unproductive things, learn Perl. Also learn to use cron.
Cut that out, or I will ship you to Norilsk in a box.
My business is utterly dependent on automation.
Several years ago I had been using Visual Basic and a lot of very ugly hacks (for example, one task we had required drawing a diagram from a database -- the VB app used the dangerous SENDKEYS function to activate and send simulated keystrokes to coreldraw to perform the drawing. Similar kludges existed for making CDs, etc.)
The problem I had with Windows/VB was there was so little command line support by common windows applications. With Linux it's actually been the opposite -- you're far more likely to be able to get the job done on the command line than by somehow communicating with the GUI. Most applications -- be it burning CDs, printing files of a particular format, processing databases, etc -- are controlled by command line unless you absolutely need full GUI to get the job done.
I've found a combination of bash shell scripts and Python code can do pretty much anything I can imagine. Some things that were virtually impossible in the windows environment can be done very easily under linux due to the great command line support for most applications. Also, since file formats are open, it's possible to do things like generate XML under Python that is a formated spreadsheet readable by Gnumeric -- something you just could not do in the Windows environment without essentially running Excel by remote control to build things cell-by-cell.
The big plus was the scripting code was far simpler, much shorter, and since it didn't depend on wierd hacks like sendkeys, more reliable. (I still use Windows and VB, but now it's just all nice, in-application scripts rather than trying to integrate everything.)
I will say that scripting a GUI apps is a bit harder than VB on windows, primarily because the VB-Office integration is much better. But I'm more than happy to trade a few pretty buttons for "dothistask -a -b -c" on the command line.
One of Apple's best kept secrets is (and always has been) the astonishing power of AppleScript.
By adding a few simple functions and classes to your program (read: there's no reason for a developer NOT to implement applescript in their program), all programs can talk with each other, control one another, etc. through a common, scriptable interface.
This interface is applescript. It's a natural-language scripting language (almost as easy to learn as BASIC).
The concept is simple, each program has a 'library' of functions the program can provide to the user or other functions, as well as controls which are input-only (ie. an interface for skipping to the next song in iTunes). Any program can access these functions, and pass them to other programs through a ridiculously easy language.
I've always wished that a similar interface would exist between platforms, and even over a network. Imagine how great it would be if we could transparently tell our computer at home to stream us some music at our office (sorry I can't think of a better example...).
Actually, I believe the original GNOME project aimed to do something very similar to what I described above, however, it failed it's key original goal primarily as a result of hasty development to compete with KDE. And it was a real pity, as GNOME had so much more potential than KDE based upon the original goals of the project.
-- If you try to fail and succeed, which have you done? - Uli's moose
After hours of searching for macros I can say this is something missing in linux, yes the command line is very efficient but sometimes you do want to automate things that cannot be done with a command line.
I found xnee which is an X macro recorder/player, use both keyboard and the mouse. It isn't perfect, but with some tweakings it can do a lot of stuff. As far as I know, I'm still waiting for their GUI so for now you'll have to use it on the command line only.
One advice, if you use xnee, don't change your widgets or fonts, if you record a macro to press a button and you change the way this button is displayed, for example it is smaller, then xnee won't be able to click on it.
Write a script in bash or perl -- it can do *anything*.
Then have xbindkeys, a simple program that runs commands when you tap specified key combinations, set up to trigger it.
Many window operations can be performed from the keyboard in powerful window managers like sawfish.
Making your environment dance at the touch of a key is what Linux does best.
May we never see th
Asking for a "Macro language" on a UNIXlike system is like asking for an automatic transmission on a sportscar. They just don't belong together.
In UNIX we have programs that do stuff. Then we have programs that implement graphical user interfaces to those programs. We don't write "macros" to click widgets in an automated way, we write new programs (often in easy to use scripting languages) that automate those underlying programs that do useful stuff to create new things. And if needed we then write new graphical interfaces to these new programs.
Yes, because of the infection from migrating Windows/Mac programmers and programs we now have some exceptions to those rules, like OOo and Mozilla; but they are exceptions. And there are plenty of toolkit web browsing programs (wget, lynx, links, assorted Perl modules, etc.) and OO.o is rapidly being assimilated into the UNIX Way and becoming scriptable for truly useful work.
Democrat delenda est
I resent your paraphrase. Because of this I am not compelled to help you, but I will anyway because I am arrogAnt. If I were in your situation, I would write a perl script that uses this module (hey look it that! it's written by the mozilla people!) to automate your javascript interface tasks.
But as long as your method is working, by all means, keep using it.