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
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.
"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
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.
Not to start a flamewar, but I think this is a bad answer. You're saying that "UNIX is like this" when really what it is "Linux is like this now". Typically, UNIX has been by and for geeks, which explains it's heavy weighting towards command line solutions. That's not the way it has to be, MacOS X has changed what UNIX has to be.
Macro languages an infection? You're actually giving away a lot of power. Macro programs aren't just for n00bz. True macro languages also have conditionals. This allows smart control over the programs state at all times, whereas command line interfaces only allow it at program startup. You're giving away a lot of control, but it seems saying it's bad to have that control because some people find that control easier. Apple got it right with Apple Events in System 7 in later. You got a framework for consistent representation of program state and actions. AppleScript was the first programming language, but now other langauges have bindings, and I believe AppleScript has fallen out of favor for MacOS X.
A better answer would have been: macro languages in general are only useful when the applications export their functionality in a consistent manner that can be easily used. It's easy for programs to hook into Windows event loops or access Apple Events because of their API consistency. UNIX/Linux just doesn't have that tradition, though it's improving with KDE/Qt with DCOP and multiple languages with DCOP bindings. GNOME probably has this too, but I don't know much about it.
Hmm, that last paragraph was too technical. Maybe, more simply: "Linux doesn't have the required amount of consistency yet, but as soon as geeks realize it's cool to be able to have macros that control multiple programs, we'll have the hooks written in a week. =)"
> Is this funny, insightful or flamebait -- you be the judge.
Yes, yes it is.
Python is for a different sort of mindset than Perl, a mindset that is less
comfortable with having multiple different ways to accomplish the same thing,
more comfortable with having one obvious way to do things, a mindset that
prefers objectual programming over contextual or functional programming, a
mindset that doesn't think significant whitespace is evil. If you find that
you don't like Perl, then you should give Python a try, as you might like that.
(Conversely, if you find that you don't like Python, you should try Perl.
They're really quite different in style.) The languages are both VHLLs, and
so they're both suitable for modern programming (as opposed to, say, C, which
is not, unless you're doing some inherently low-level stuff that *requires*
micromanaging resources, such as device drivers, bootloaders, kernels, &c).
I recommended Perl not because Python is bad, but because Perl is what I
use and what I know. (I tried Python briefly, but it didn't really take for
me. I don't like its typing system. That's just a personal preference.) I
don't wince when people start new projects in Python, like I do when they
start new projects in C.
Cut that out, or I will ship you to Norilsk in a box.