|Problems? Is your data what you think it is?|
Automation of the Facebook "Graffiti" App with X11::GUITestby cavac (Chaplain)
|on Dec 24, 2011 at 21:53 UTC||Need Help??|
I hereby present to a X11::GUITest script that automates the Facebook App "Graffiti". There are quite a few of those tools available on the internet, i just thought of doing an open source Perl version of it.
Also, it's quite easy to adapt to other programs and apps. See after the code for details on usage to give you an idea on how to do that.
Note: This is a simple script i wrote a few weeks ago. It currently only runs on linux, but it is trivial to change it to use WIN32::GUITest. Frankly, i didn't bother to boot up my Windows partition right now, since i'm currently running a database upgrade on my Linux. But since i adapted that script from my MSPaint automator in the first place, porting it to windows would be trivial.
First, change the name of the image file at the indicated place in the code (currently, only BMP supported for simplicity). The most time generally used up on changing colors, so prefer a 256 color or greyscale indexed BMP. Also important to know: There is a slight problem with opacity when using the smallest 1-pixel brush, so the program is designed to use the 2-pixel brush and scale the image accordingly.
Open the Facebook Graffiti app in a browser side-by-side to your commandline or debugger window - you need to see the programs output. Also, set the Graffiti to a blank canvas (or whatever rocks your boat), change the opacity to nearly full and select the second-smallest brush.
Then start the script. At startup, it optimizes the rendering sequence in a way to use the least amount of color changes. Basically, it scans the image and puts all the same color pixel coordinates into the same hash-of-arrays bin. I could have paint-time scans of the whole image, but i figured this way is easier to change the algorithm later or change the order in which colors are applied to the canvas (Graffiti has an option to play back the painting generation).
Now, the script asks you to place the mouse at certain points on the screen, which is effectively a calibration for screen coordinates for when the script takes over control of your mouse and keyboard: First, on the color select button, then (click on the button to open the color menu) after the last digit of the HEX display for the color code and then (press enter to close color dialog) at the start pixel where you want to place your painting. Everytime you'll see a ten second countdown.
At this point you'll see the "GET READY!" 10 second countdown. This is your last change to either stop the script or make sure that for the duration of automated paint operation the windows wont move and your (hardware) mouse stays untouched. Unplugging/switching of the mouse during the countdown is a good way of assuring that.
Ok, you calibrated the mouse correctly, let the final countdown run and you have made sure the (hardware) mouse wont be moved. You'll also took out that good book you always wanted to read (since this will take a while).
The mouse pointer starts to move on its own painting pixels and sometimes opening the color dialog. When that happens, the mouse pointer clicks at the end of the HEX number for the colors, the script backspaces and puts in automatically the new color value. Then it presses ENTER to accept and close the dialog, continuing to paint more pixels. This process repeats until minutes (or hours) later the final picture appears and the script finishes.
The principle is simple enough. Adapting it to other Web- or offline graphic tools is more or less a matter of writing down how to do some operations manually and then changing the setColor() and doPaint() operations accordingly. It's also quite likely that quite a few graphic tools could be automated with no programatic changes whatsoever - just with doing the calibration required anyway.
BREW /very/strong/coffee HTTP/1.1 Host: goodmorning.example.com 418 I'm a teapot