Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
GUI Software

Open Source Macro Programs? 88

Posted by Cliff from the automating-your-mouse-clicks dept.
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?"
This discussion has been archived. No new comments can be posted.

Open Source Macro Programs? More

Open Source Macro Programs?

Comments Filter:

  • Great timing! (Score:3, Interesting)

    by heldlikesound ( 132717 ) on Thursday February 26, 2004 @06:51PM (#8402567) Homepage
    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?

    • WSH (Score:2)

      by JMZero ( 449047 )
      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.

    • Re:Great timing! (Score:5, Informative)

      by TheWanderingHermit ( 513872 ) on Thursday February 26, 2004 @08:15PM (#8403331)
      OOo has a macro recorder in 1.1.1 and later, so you can record a macro. If it includes opening files, you can edit the macro later and find a new way to specify files.

      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.

  • command line? what apps? (Score:3, Interesting)

    by Tom7 ( 102298 ) on Thursday February 26, 2004 @06:59PM (#8402661) Homepage Journal
    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.

    • Re:command line? what apps? (Score:1, Informative)

      by Anonymous Coward

      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.

  • Then why do you want to switch to linux? (Score:5, Informative)

    by Lord Bitman ( 95493 ) on Thursday February 26, 2004 @07:00PM (#8402671)
    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 [nist.gov]
    • (Amongst) The problem(s) with linux GUIs is that they require the user to need a in-depth knowledge of how the system works. Hasn't this always been the case? So while the answer to a windows programmer looking to switch might be "learn how to script", this is simply not an option for the vast majority of computer users who were attracted to the "plug and play" mantra. And maybe that's why OS X (*shudder*) is quite dangerous to the linux community. It's a good thing Steve Jobs and Co. are arrogant asses

  • Shell? Perl? ;-) (Score:5, Informative)

    by PaulBu ( 473180 ) on Thursday February 26, 2004 @07:01PM (#8402683) Homepage
    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.
  • Find a scripting language. Learn it. Have fun.

    For what it's worth, I like bash and am learning perl, but many prefer python as well.

    • Actually, what really scares me is that I've been finding myself (as a Web developer) doing batch file processing with an interactive PHP session. 6-8 lines of php and I can do all sorts of neat and nifty things - doubly so with shell_exec (or the `backtick` operator - same functionality) if I need to do a move or rename or whatnot. I'm finding that much easier than raw shell stuff with foreach i (`ls`) if only because I'm so much more comfortable with php.
      • I can understand the desire to use whatever you know best for programming to the exclusion of others. Whenever you have a hammer everything starts looking like nails. But you need to know what your goal is. Perl is great at being the glue between anything, but sucks for maintainability(god knows I love regex but try explaining it to a coworker) PHP is great at web apps but blows on a command line. Python seems to fit the bill for being understandable but the performance is up there with quickbasic. Ja
        • You need to figure out who is going to keep this and what are you targeting when you pick the language. Otherwise your likely to pick wrong.

          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)

    by uradu ( 10768 ) on Thursday February 26, 2004 @07:08PM (#8402743)
    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.

  • KDE 3.2 (Score:4, Informative)

    by pcbob ( 67069 ) on Thursday February 26, 2004 @07:09PM (#8402758) Homepage
    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.

  • bash (Score:5, Informative)

    by _aa_ ( 63092 ) <j&uaau,ws> on Thursday February 26, 2004 @07:18PM (#8402831) Homepage Journal
    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 [gtk.org] application should do it.
    • I am responding to this post and not the quoted one below because it captures the arrogence of the development community. I swim in a sea of web interfaces that use java script popups, flash controlled buttons, java applets and god only knows what that are required to do my job.

      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) GUI

      • Re:bash (Score:2, Informative)

        by _aa_ ( 63092 )
        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 [cpan.org] (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.

  • macros are scripts, and scripts are macros (Score:4, Informative)

    by chrisopherpace ( 756918 ) <cpace@@@hnsg...net> on Thursday February 26, 2004 @07:25PM (#8402889) Homepage
    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 [nist.gov] 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.
    • Through extensive use of Macro Express (and Keyboard Express) at work, I think what the writer may be interested in, is more scripting GUI commands with some logic and text processing built in. Shell scripts and languages like Perl are great, but don't suit all needs. I personally had been thinking about reimplementing ME under GTK/QT but haven't decided if it would be worth the time/effort.

      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

  • Those programs are band-aids (Score:1, Insightful)

    by Anonymous Coward
    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 c
    • 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 mach

  • The best macro program is... (Score:5, Funny)

    by Imperator ( 17614 ) <slashdot2.omershenker@net> on Thursday February 26, 2004 @07:45PM (#8403050)
    m4

  • Tcl, REXX, AppleScript (Score:3, Insightful)

    by clem.dickey ( 102292 ) on Thursday February 26, 2004 @08:33PM (#8403447)
    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. (Score:5, Informative)

    by jonadab ( 583620 ) on Thursday February 26, 2004 @10:56PM (#8404582) Homepage Journal
    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.
    • Thanks =) I think that answer provided the level of detail I was looking for.
    • Perl isn't called a "glue language" for no reason.

      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)

        by jonadab ( 583620 )
        > 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,

  • bash/python + command line options (Score:4, Informative)

    by mercuryresearch ( 680293 ) * on Thursday February 26, 2004 @11:55PM (#8404992) Journal
    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.

  • Applescript!! (Score:5, Interesting)

    by moosesocks ( 264553 ) on Friday February 27, 2004 @02:01AM (#8405724) Homepage
    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.
    • AppleScript can currently be done over IP. It's not exactly seamless, but it can be done. That's half of 'cross platform and over a network'.
    • Minor quibble... Apple Events are the things that controlled your program. AppleScript is just a language binding (I believe there are others now). But I always loved AppleScript/Apple Events. Very cool tech ahead of it's time. True AppleEvent capable programs actually had a detachment between the menu/GUI interface and the underlying code. The GUI code just sent AppleEvents for every GUI action. The advantage to this? Now your app was recordable, you could record every action you took in your porgra
      • Command Line interfaces only allow control at app startup, whereas macros that can control deep event models (like AppleEvents/AppleScript) can control program state over the life of the app. Very powerful.

        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
    • Should work like a champ on Linux.
  • If you want, try to see if your current applications run 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 /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.

  • xnee (Score:2, Interesting)

    by Zurd3 ( 574979 )
    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 chan

  • xbindkeys + scripts (Score:3, Informative)

    by 0x0d0a ( 568518 ) on Friday February 27, 2004 @04:13AM (#8406198) Journal
    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.

  • Asking the wrong question (Score:3, Informative)

    by jmorris42 ( 1458 ) * <jmorris&beau,org> on Friday February 27, 2004 @12:46PM (#8408926)
    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.

    • Re:Asking the wrong question (Score:4, Interesting)

      by cant_get_a_good_nick ( 172131 ) on Friday February 27, 2004 @09:27PM (#8413698)
      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. =)"
      • I believe AppleScript has fallen out of favor for MacOS X

        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

Slashdot Top Deals

The biggest difference between time and space is that you can't reuse time. -- Merrick Furst

Close