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 found thin new think I think that they call it BASH ;)
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
ever heard of "scripting"? with bash, perl or whatever? aren't the "macros" a pale shadow of scripting anyways???
is there a compo to get these things submitted to slashdot or what?
-
in open source world mixing different languages works out too nicely usually...
world was created 5 seconds before this post as it is.
Windows Scripting Host should provide all the functionality you need. It's fairly easy to use, even if the target program has a complicated UI.
I've done this sort of batch convert with it before without much hassle.
Let's not stir that bag of worms...
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
Has anyone thought about adding embedded Python to OpenOffice for macro usage? If you consider what else Python can do, HTTP requests for example, you could really extend OpenOffice's documents.
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.
For what it's worth, I like bash and am learning perl, but many prefer python as well.
This sig no verb.
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.
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?"
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.
m4
Gates' Law: Every 18 months, the speed of software halves.
It makes sense to me. What's your problem with it?
I'd rather be lucky than good.
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.
Actually it makes sense if you realize the word 'means' here is used in the sense of, 'Living beyond your means.' In other words, Money.
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
If you want, try to see if your current applications run under WINE.
/SELECT NEAREST TARGET/ /FOLLOW TARGET/ /ATTACK/ /WAIT TEN SECONDS/ /LOOP/. I can gain 1-2 levels per night by doing nothing but killing rats. It's runs Windows 95 too, so it should run fine under wine.
I use a program called "Perfect Keyboard", which is a mouse and keyboard macro recorder/playback. It's great for leveling in MMPORGs. I have a spare Computer running a continious loop to
I really hate Dan Patrick.
KDE applications use DCOP to script applications. You can access it from various languages, including shell scripts using the dcop command-line application.
KDE's Kommander lets you construct simple scripts and dialog-based applications to run shell commands and control other KDE applications through DCOP.
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
I've wanted to switch to Macintosh for quite a while, but my work requires a lot of GUI-intensive tasks. For these tasks I use my mouse to click on links in Internet Explorer. So far I've looked for equivalents for Macintosh, but have been unsuccessful. Does anyone know if the Macintosh will support a GUI?
*sigh*
Do I have an answer? Sorry, no. I'm a big fan of scripting, but it's totally impractical when I think of how fast it is to record and replay macros.
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
> And I'd guess there are macro recorders for OS X, right? Apple has been pushing AppleScript in a big way, altough the recording aspect of it has been busted (in my opinion) since the dawn of OS X.
-- http://vectorvector.tumblr.com/
The grass is always greener... Or more basically, humans are never satisfied.
With the Adobe solution, I would need to buy a copy of not only Photoshop Elements but also VMware and Windows. Or does CrossOver Office run the latest version of PS Elements?
What makes you think most people have the time, energy, or desire to learn to work with computer language? If you're a programmer or CS person, it makes sense, but it would be horribly inefficient for the typical person to do so. The amount of knowledge necessary to even approach coding of any kind vastly exceeds the payoff for almost everyone outside of the computer industry. We're not pointing and grunting here, we're mechanizing a task. Rather than repeatedly perform the same actions, we're creating machines to do our menial labor for us. That's advanced, not primitive.
G