Open Source Macro Programs? 88
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?"
Great timing! (Score:3, Interesting)
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?
WSH (Score:2)
I've done this sort of batch convert with it before without much hassle.
Re:WSH (Score:2)
Re:WSH (Score:2)
Re:Great timing! (Score:5, Informative)
Star BASIC (or OOo BASIC, if you prefer) is a powerful scripting language for OOo that lets you work with recorded macros, or writing your own macros. (At one point I was considering writing a full application in OOo BASIC and basing everything on OOO.) It is also possible to specify a macro on the command line, so you could make a script that would run OOo, start a macro, run the macro, then exit OOo.
You can also automate OOo with Java (or Python, or C++).
Scripting OOo to do conversions is VERY simple. there is someone on the OOo Users mailing list who has a website with samples for doing conversions (although I think most of his conversions are for Writer files, the idea would work on Impress files).
If you really want ideas for scripting OOo, get on the mailing lists. There's a User mailing list, an API-DEV one that is good for anyone doing any programming of OOo, and a Scripting Framework one.
Hope this helps you find a way to automate what you're doing.
Re:is this a trick question? (Score:2, Insightful)
.
Re:is this a trick question? (Score:5, Interesting)
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.
actually, Gnome (and hence Linux) does it well (Score:5, Informative)
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
Re:actually, Gnome (and hence Linux) does it well (Score:2)
Re:actually, Gnome (and hence Linux) does it well (Score:1)
Re:actually, Gnome (and hence Linux) does it well (Score:2)
Re:actually, Gnome (and hence Linux) does it well (Score:2)
The Gnome implementation of the Accessibility Toolkit uses Bonobo, so as long as your favourite language has Gnome bindings which supports Bonobo, you're set.
-mike
KDE as well, using DCOP (Score:1, Informative)
Re:KDE as well, using DCOP (Score:2)
Re:is this a trick question? (Score:2)
Think of programs like kazaa. Say you have a home network and five users who all connect and use kazaa. Wouldn't it be nice if you could connect to your kazaa session from any machine? Or allow all users to use one kazaa "daemon" and run a seperate client to search for and download files?
So in UNIX you write a server that runs as a daemon on one host, then you connect to it
Re:is this a trick question? (Score:1)
Thats what we call mldonkey [nongnu.org].
Re:is this a trick question? (Score:2)
Re:is this a trick question? (Score:2)
OK, so you are a Mac geek and Linux doesn't work like you are used to. Fine. I have tried AppleScript/OSA and I happen to think that it sucks: it's a lousy language, it's tedious to use, and it doesn't work quite like I expect it either.
You know, that'
Re:is this a trick question? (Score:2)
Actually, I see it the other way... sutomating GUI apps via macros is a kludge that is necessary when the apps don't have a powerful command-line interface... which most Linux apps have.
Re:is this a trick question? (Score:2)
But, no matter how many times you say it, it's not true. Without writing additional C code (or compiling someone elses) how can I ask my window manager what windows are open, and then perhaps switch to the one I want? Or, how do I ask my email client for a list of names in my addressbook? The sad thing is that most Linux and *nix apps
Re:is this a trick question? (Score:2)
I disagree, at least I don't think that's a universal answer. Macro languages allow you to make automated decisions based on current program state. Command line interfaces only allow control based on initial program state. Sometimes you don't care about the distinction, but it's still a very powerful difference. Macro
Re:is this a trick question? (Score:1)
ever heard of "scripting"? with bash, perl or whatever? aren't the "macros" a pale shadow of scripting anyways???
Hey, I was going to suggest a C pre-processor, but I guess in the windows world macro == script
Re:is this a trick question? (Score:2)
Jurgen
command line? what apps? (Score:3, Interesting)
Re:command line? what apps? (Score:1, Informative)
The Gimp.
800+ photos, from several family reunions, that my dad had scanned at various large resolutions and cleaned up by hand. Now all the same size, with a consistent naming strategy and overall brightness/contrast within tolerable limits. Collated together into an HTML-based slideshow with thumbnails, and mid- & large-sized zooms. Manual and auto-play versions. Everyone goes home with a CD of it this summer.
Thank you Perl.
Platform compatibility? (Score:1)
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?
Then why do you want to switch to linux? (Score:5, Informative)
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 [nist.gov]
Welcome to Linux! Now, GO AWAY! (Score:2)
Re:Welcome to Linux! Now, GO AWAY! (Score:1)
Re:Then why do you want to switch to linux? (Score:2)
Shell? Perl? ;-) (Score:5, Informative)
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.
Re:Shell? Perl? ;-) (Score:4, Informative)
--
Evan
Re:Shell? Perl? ;-) (Score:4, Informative)
--
Evan
Re:Shell? Perl? ;-) (Score:2)
Paul B.
The world will be saved by $scripting_language! (Score:2, Informative)
For what it's worth, I like bash and am learning perl, but many prefer python as well.
Re:The world will be saved by $scripting_language! (Score:2)
Re:The world will be saved by $scripting_language! (Score:2)
Re:The world will be saved by $scripting_language! (Score:2)
Exactly so. In this case, I'm looking to write a one-off just to do something in batch - do I care about runtime efficiency? No. Maintainability? Heck it's not even hitting a file. All I'm looking for is something that works, and works how I expect, hopefully the first time. In that case, there is no wrong pick.
Learn a proper interpreted language (Score:5, Insightful)
KDE 3.2 (Score:4, Informative)
bash (Score:5, Informative)
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 [gtk.org] application should do it.
Re:bash (Score:1)
Re:bash (Score:2, Informative)
But as long as your method is working, by all means, keep using it.
macros are scripts, and scripts are macros (Score:4, Informative)
Re:macros are scripts, and scripts are macros (Score:1)
I haven't had time to explore your sugestion of Expect yet, as I'm still at work, but it suggests combining it with T
Re:macros are scripts, and scripts are macros (Score:1)
Re:Todays quote? (Score:1, Offtopic)
Re:Todays quote? (Score:2)
Those programs are band-aids (Score:1, Insightful)
Perhaps band-aids are all that's needed (Score:2)
The best macro program is... (Score:5, Funny)
Re:The best macro program is... (Score:4, Funny)
Re:The best macro program is... (Score:1)
Tcl, REXX, AppleScript (Score:3, Insightful)
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. (Score:5, Informative)
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.
Re:Perl. (Score:1)
Re:Perl. (Score:2)
He's right. You don't want to get any of that on your fingers. ;-)
Perl is perfectly suited for those applications where no one else will ever have to maintain the code. This certainly sounds like one of those cases. If, on the other hand, you expect others will need to maintain it, you might be better off using a more maintainable language, such as Python. Similar features, more legible.
Oh, and if this will require learning a new language for you, y
Re:Perl. (Score:2, Interesting)
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,
bash/python + command line options (Score:4, Informative)
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.
Re:bash/python + command line options (Score:4, Informative)
You can get a lot done in Windows with VBA and calling on routines using OLE. It's evil evil stuff, but it works and doesn't take the brute-force sendkeys kind of route... that stuff is a hack.
Check out what the sick Perl bastards have been up to : http://www.xav.com/perl/faq/Windows/ActivePerl-Win faq12.html#use_ole [xav.com]
I've always had trouble finding good docs on this stuff when I try to take advantage of it.
Applescript!! (Score:5, Interesting)
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.
Re:Applescript!! (Score:1)
Re:Applescript!! (Score:2)
Re:Applescript!! (Score:1)
Well, the mac or unix ways are quite different, as I understand (never used Macos). If I understand well, in macos, for example, applescript will start the program, fill some cells, print the spreadsheet, and close the program.
In Unix, I would create a script (shell, perl whatever) putting together ma
Re:Applescript!! (Score:1)
Try Wine (Score:2)
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
xnee (Score:2, Interesting)
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 chan
xbindkeys + scripts (Score:3, Informative)
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.
Asking the wrong question (Score:3, Informative)
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.
Re:Asking the wrong question (Score:4, Interesting)
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. =)"
Re:Asking the wrong question (Score:2)
I don't think so. While the original intentions of haveing different AppleScript dialects for different (human) languages are gone, AppleScript is still undergoing active development - with 10.2 (I think) it even gained the capability to script the GUI, which makes it possible to control even otherwise non-scriptable applications. Plus you can mix and match AppleScript code with that of any other scripting language (using the CLI AppleScript interpr