| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
![]()
This section:
Blog postings by Operational Dynamics partners and staff
Use the links at top left for a consolidated feed of all the posts made on this
site.
Please note the disclaimer at the bottom of this page.
Wed, 21 Nov 2007
Automatically rendering and capturing screenshots
One of the things I’ve often noted in the API documentation for the various GNOME libraries is that the examle screenshots always seem out of date. I think this is mostly because the look and feel we all interpret as “modern” is just that which happens to be shipping with the current version of the GNOME Desktop we’re using — and that default changes fairly frequently.
As I’ve been working on the GTK coverage in java-gnome, I’ve had in the back of my mind that it would be really cool if we had illustrations of the various Widgets and whatnot under discussion. More than cool, actually; a lot of the people developing with java-gnome are experienced programmers but new to Linux and the GNOME Desktop, so it’s probably pretty important that we help them along in learning which controls on their desktop correspond to which Widget classes. Capturing such screenshots manually is a bit of a pain, though, and even if we did that we’d still end up with them looking out of date within a year or so.
So I had a bit of fun last week and knocked something together that would automatically take screenshots of individual Windows or fragments thereof such that we could use them in the java-gnome API documentation.
Snapshots
First I cooked up a scheme to make it easy to write the little programlets that draw the Windows and Widgets (I used the term Snapshot to refer to these; nothing as elegant as the JUnit API, but hopefully it’ll improve over time). Then I wrote a harness to instantiate the sequence of Snapshot programs and to capture a screenshot of each one in turn.
GNOME ships with a tool in gnome-utils called gnome-screenshot which is handy, but a bit too focused on being a user driven program and is not available as a library in any event. So we pulled out the parts that actually capture the image (my Lord, talk about ninja voodoo X programming — I remember working directly with Xlib back in the late 80s;I am so glad we don’t have to do that anymore) and made it accessible programmatically. So all Harness has to do is something like:
window = snapshot[i].getWindow();
window.showAll();
window.present();
pixbuf = Screenshot.capture();
and then save the Pixbuf to disk in the right place so that <img> tags in our JavaDoc can pick them up. I did up examples for Window, Button, a few MessageDialogs, and TreeView. They’ll be in java-gnome 4.0.5 which will be out within the next week or so.
Off screen
If you did this as a zillion Windows popping up in front of you, though, you’d probably end up capturing the wrong thing if you accidentally changed apps or something. So instead I tried to figure out how to do it off screen. The solution I came up with was using the virtual X server that ships with xorg, Xvfb. By doing:
$ Xvfb :1 -ac -screen 0 640x480x24 -wr
we have a new X server running on :1, and then by passing --display=:1 to the Gtk.init() call used to initialize GTK, the Windows rendered by the program will be sent to the virtual server, not the desktop running on :0, and then we can take our screenshots there.
I’ve had this in mind for a while as a way to do unit tests that absolutely need to have the Window mapped to the screen. Unlike the unit test scenario, though, there’s a catch: you want the Windows to look right, ie just as they would if they were on a user’s desktop. That doesn’t happen in a naked X server though; you need a window manager running and also the magic program that makes the GTK themes according to your current preferences:
$ metacity --display=:1
$ gnome-settings-daemon --display=:1
otherwise you get that rather ugly default built-in GTK fallback theme and no window decorations, which would defeat the whole point of the exercise. So hook that all up to be exec()d when the Harness program starts and everything works great!
I’ll have to remember to switch themes back to Clearlooks before generating the screenshots for our next release… :)
AfC
Category Specific Feeds.
Use these links for an RSS or ATOM feed limited to this category and its descendants.
Technorati Profile


