Category Archives: June 2007

Creating the GNOME 2.18 Live Media: An interview with Ken VanDine

Paul Cutler interviews Ken VanDine, founder of Foresight Linux, on building images for the recent GNOME 2.18 Live Media release. Ken discusses his goals in helping create new GNOME Live Media, the tools he used in putting the different images together, and his plans for future GNOME Live Media releases.

Short Intro

  • Located in: Durham, NC
  • Profession: Director of Management Engineering, rPath, Inc
  • Nickname on IRC: kenvandine
  • Homepage or blog:


How and when did you get involved in GNOME?

I have been a GNOME user for many years now and probably really got more involved in GNOME advocacy just a couple years ago shortly before I created Foresight. I realized there was some very interesting work being done on desktop tools, but they were hard to integrate into existing distros. There just wasn’t an easy way for users to see what was on the horizon and how great Linux on the desktop was becoming. So I created Foresight in 2005 to showcase some of these technologies that I thought were going to make a big impact. Things like Beagle, Howl (replaced by Avahi since), Mono, etc.

I also found that all the really innovative work was being done in GNOME. GNOME is really making the Desktop simple and appealing to new users. I knew I preferred GNOME, but when I started to think about how we could get more new Linux desktop users, GNOME was really the only choice. GNOME keeps it simple, where traditionally Linux has been about being infinitely configurable. This is not a winning philosophy when it comes to attracting new users. Simple is better, however the power users prefer more flexibility and GNOME also provides that. (Although I think we need a better tool for advanced configuration than gconf-editor). So this got me really fired up to create just that Desktop experience, and Foresight was born. I also started contributing articles to GNOME Journal focusing on topics that helped new users.

You recently led the effort in creating GNOME Live Media, including a new LiveCD and a number of virtualization images for the recent 2.18 release. What motivated you to create the Live Media?

I have been interested in GNOME advocacy for awhile and just wanted to help. I also happen to work with rBuilder on a daily basis that can build a variety of virtual image types including a LiveCD, so I have quite a bit of experience now in doing so.

You helped create four types of Live Media, the LiveCD, a VMWare image, a QEMU image and a Microsoft VHD image. What led you to create more than just a LiveCD?

Primary reason is to make it as easily consumed by as many people as possible. VMware player is free and easy for anyone to get and hence the most popular. LiveCD requires burning a disc and rebooting. Parrallels is popular for Mac, but it also has versions for Windows and Linux. QEMU is just dirt simple to get running on Linux. Not sure about Microsoft Virtual PC, but it is just an extra click to create it, so why not?

Within two weeks, you released 4 different types of images twice, once with the GNOME 2.17.92 testing images, and then the official GNOME 2.18 images on release day. What tools did you use in creating the Live Media? How much time did you spend in creating the images?

It actually isn’t that much work to create the live images… Not much more than clicking a few buttons in rBuilder since I already maintain all the packages in Foresight. Packaging new GNOME versions is just something I would be doing anyway. Our goal is to always provide GNOME beta through final release to Foresight users. So we get some good testing the weeks leading up to GNOME release day.

Using the rPath tools make it pretty easy to stay on top of packaging GNOME. Conary as a package manager and rMake as the build tool just make it easy to do continuous builds as tarballs that show up on the ftp site.

Was there anything unexpected that caught you by surprise in putting together the Live Media? What was the biggest challenge you had to overcome with the release?

The biggest challenge was actually bugs in the LiveCD image creation in rBuilder. It had been well tested, but mostly for things without Xorg. And LiveCDs that had been built with Xorg used the old monolithic Xorg 6.8.2. There was a bug in determining the default runlevel since Foresight ships Xorg 7.2. So this did uncover a bug in rBuilder which was fixed very quickly, and I was able to do some good rBuilder testing.

Are you planning another Live Media release for the GNOME 2.20 release cycle? If so, what would you do differently?

Definitely! I was very pleased to do it for 2.18 and plan to keep it going. In fact, something I hadn’t considered before doing this was the benefit to the translators. I got some great feedback from them this time. It seems they hadn’t had a chance to really see their work yet. For the next release, I will be creating Live images well before 2.20, maybe even before the beta. This should allow more visibility to folks that don’t want to actually build GNOME for themselves. They can download snapshots, test their translations… or experiment with new features to provide feedback for things like writing release notes or even filing bug reports.

How can others get involved in helping out with the Live Media release?

I would love to see more testers, some folks that could download the images and report issues quickly. This was the most time consuming part of the process, booting each image and ensuring everything worked as desired. The Foresight Linux project would welcome developers, which is where all the real work that leads to the Live images is done. Seeding the torrent is also a great way to help.

Can you share any download statistics about the different images that users have downloaded since the release of the Live Media on March 15th?

We had about 35000 the first 3 days but they have slowed now. I think we are getting around 1500 per day still.

Thank you to Ken for creating the Live Media releases for the GNOME 2.18 release, and for taking the time for this interview. Ken is the founder and lead developer of Foresight Linux.

GNOME 2.18 Live Media images are available for download at

About the author

Paul Cutler has been a GNOME user since 1999, and converted to using Linux full time in early 2005. He has lurked on many GNOME mailing lists for a number of years, and is trying to get more involved in the GNOME community starting with this article. Paul recently joined the Foresight Linux team helping with documentation and marketing.

Discuss this story with other readers on the GNOME forums.

Exercising Your Application With Accerciser

Eitan Isaacson introduces Accerciser, a Python-based accessibility testing tool which allows testers and developers to assure that their applications are accessible.



GNOME enjoys the benefit of being accessible. A computer program is accessible when it provides the necessary means for people with disabilities to access it’s user interface. GNOME and GTK+ provide the infrastructure for this to be possible.

As an application developer, your GNOME application is probably largely accessible, even with no effort on your part. Like every other feature in your program, it’s accessibility could be enhanced, and made more usable to people with disabilities.

In order to do this, the accessibility of your application must be exercised. Accerciser is the accessibility exerciser you were looking for.


Accerciser is a Python-based accessibility testing tool. Like a Swiss Army Knife, it has many uses. The primary use of Accerciser is to allow testers and developers to assure that their application is accessible.

Some of Accerciser’s key features include:

  • Accessible – Accerciser’s User Interface is accessible. An LSR extension in planned for the future to make Accerciser more usable via LSR.
  • ORBit, not cspi, based – Like the modern LSR and Orca screen readers, Accerciser uses pyORBit to talk AT-SPI with other applications. The legacy cspi module is avoided. In fact, Accerciser 0.1.2 will be the first application to adopt the new Python AT-SPI bindings that will ship with the next version of AT-SPI.
  • Customizable UI layout – Move tabs to different panels or even separate windows to view them concurrently.
  • Quick accessible selection – Besides navigating through the tree view of the accessible applications on the desktop. A user could quickly select any visual accessible object on the desktop by pointing at it with the mouse cursor and pressing a hot key.
  • Plug-in architecture – Accerciser has an easy and simple plug-in architecture. A user with a specific test case could quickly create a plug-in that provides the needed controls and information.

In the following sections we will review some of Accerciser’s default plug-ins.

Interface Viewer

The interface viewer plug-in gives the basic information and controls that are provided by the various interfaces each accessible object has. When accessible objects are selected in Accerciser, the Interface viewer will allow the tester to quickly review the supported interfaces of the examined accessible, to retrieve the information the interface provides, and to manipulate the accessible object through each of the interface’s methods. For example, when a button accessible is selected, it is possible to view the provided text in the Text interface view, and to have the button clicked in the Action interface view.

Event Monitor

Assistive technologies rely heavily on the events that desktop applications emit via AT-SPI. Accerciser provides an event monitor plug-in that allows the user to view AT-SPI events as they occur. Furthermore, a user could filter the output to show only the types and sources of events that she is interested in.

Python Console

Since Accerciser is a tool for the technically inclined, it must provide an easy method for allowing users to peak under the hood and explore AT-SPI. In the IPython console users could do just that, with the benefit of tab auto-completion, command history, and pretty output. When an accessible is selected in Accerciser’s tree view it could automatically be manipulated in the console.

Script Recorder

Accerciser’s script recorder allows users to record keyboard interaction with other desktop applications for the purpose of authoring UI test scripts. Currently the plug-in supports the generation of scripts for three platforms: Dogtail, LDTP, and an Accerciser’s built-in API. Once you press the “Record” button every keyboard interaction will be recorded in to a script that could be executed later as a stand alone script.


While Accerciser might not wash the dishes piling up in your kitchen sink, it has a bit of everything for GNOME application developers and testers. Give it a try. Who knows? You might discover some facts about your application you never knew.


About the author

Eitan Isaacson currently lives in Seattle. Besides other random GNOME contributions, he is the developer and maintainer of Accerciser. Eitan’s passions include sipping high-mountain oolong tea and talking politics.

Discuss this story with other readers on the GNOME forums.

Fun with GStreamer Audio Effects

Stefan Kost describes GStreamer features that have been implemented and that are in the works, and he steps users through setting up an example with which to play.



GStreamer is mostly known as a back-end for media players like Totem and Rhythmbox. Besides that, it is used as a foundation for content creation tools like Jokosher, Buzztard, Marlin, and PiTiVi.

Recent changes make the framework more useful for creative media processing. GStreamer- (cvs) got latency handling. This allows realtime effects on live sources (alsasrc ! effects ! alsasink). Also, lots of work went into flexible data format support [int (8/16/32 bit) and float (32/64 bit)] in audio processing effects. Finally, the new jacksrc provides a bridge between the desktop applications and the professional Linux Audio world. Using the jackd daemon allows routing audio signals between applications.

What kind of effects are there?

The package gst-plugins-base mostly provides elements to convert or adapt properties such as number of channels, formats (float/int and bit-depths) and sampling rate.

In gst-plugins-good is the audiofx plugin, that brings audiodynamic, audioamplify, audioinvert, and audiopanorama elements. There is also a peak-level meter.

In gst-plugins-bad is the equalizer plugin with several equalizer variants and a spectrum analyzer. Currently, the LADSPA wrapper is also there. LADSPA is the Linux Audio Developers Simple Plugin API. On my Linux system, I have 231 elements installed, and the GStreamer LADSPA plugin makes those available for use in GStreamer.

The code repository of the Buzztard project brings more elements. First, there is a gst-buzztard module which provides some experimental GStreamer extensions, a simple software synthesizer (simsyn), and an effect called audiodelay. Second, one can install the bml, gstbml modules. This provides a wrapper like LADSPA, but this time for so called “buzz machines.” These are win32/x86 DLLs of a discontinued freeware music composer called “buzz.” Buzz comes with more than 500 free sound generators and effects. The gstbml wrapper makes most of them available as GStreamer elements. Please note that these modules are a bit more difficult to set up. If you have problems, help is just one click away.


Lets get practical! As a shameless act of self-advertisement, I recommend you to install buzztard from CVS if you want to try the examples yourself. The example also needs an up-to-date GStreamer from CVS. For the not-so-fearless, I have some screenshots:

Start the graphical editor “bt-edit.” The first tab shows the machine view. Here, you can create elements and link them together. Buzztard automatically adds conversion elements on-the-fly. To create an element, right-click the background and select an element from the context menu. For the example, choose alsasrc. Not all the elements in the list will work perfectly in a live situation at this time. In your soundcard mixer, enable recording from the microphone or provide some music on line-in. Next, add audiodelay and equalizer-10band elements. Then, wire them together by pointing on the source element (alsasrc) and dragging a wire to the target (audiodelay) while holding the shift key. The wire should become green when the mouse is over a valid target. Releasing the mouse creates the link. Repeat the procedure for audiodelay -> equalizer and equalizer -> master. The wires have a triangle in the middle showing the direction. A left click onto it allows you to change the volume of the link. A right click shows a context menu for disconnecting the elements and for showing an “analyzer dialog.” Open that option as needed for the link between equalizer and master. Finally, double-click the equalizer and the audiodelay to open their realtime settings windows. Then, you should see something like this:

Lets give it a try! Activate the loop in the toolbar and press play. You can tweak the settings of the effects while making some noise. The parameter-changes are effective right away. In the “analyzer window,” you can see the frequency spectrum of the sound and the volume level. Tweaking the knobs is nice to try out settings, but that is not all there is. Buzztard will be a music composer, and in the future, it will be able to record those parameter changes into patterns from which one can build a song. Currently, recording is not yet well-supported by the user interface.


As shown above, the functionality is there. Adding and porting more effects will be a matter of time and manpower. The LADSPA wrapper already provides access to numerous plugins. Still there is room to improve the wrapper. The GStreamer API is richer than the LADSPA API. Thus it might make sense to add more metadata to known plugins, to improve their usefulness for GStreamer applications. More effects and features are planned as a Google Summer of Code proposal. Unfortunately, GStreamer has not been accepted by Google as a project. Nonetheless, we will work on the effects.

An important point for me is to continue discussing the Buzztard GStreamer extensions with the community and make them part of GStreamer once they are ready. To give an example: we currently work on a unified preset handling interface that works across applications. If your interested or have questions, feel free to ask in GStreamer IRC.

About the author

Stefan Kost works on the multimedia software used on the Nokia Internet Tablets. In his spare time he programs the Buzztard music composer and contributes to GStreamer. From time to time he composes music and writes lyrics for his band ekso:r.

Discuss this story with other readers on the GNOME forums. 2007 Wrap-up

Davyd Madeley provides a summary of events at 2007, including video and image links for several of the presentations.

For the fourth year running, in Sydney played host to Australia’s GNOME conference: Started as a single day event in 2004, in 2007 ran over two huge days with 12 speakers presenting on a range of topics both technical and non-technical topics.

On day one, Nigel Tao told us about Superswitcher, a rethinking of the traditional desktop application switcher. He shared some ideas about how a GNOME desktop might work in the future and also showed some other neat tricks that you can do with the window management library libwnck.


Avahi developers Trent Lloyd and Lennart Poeterring then discussed Avahi, the Rendezvous/Bonjour/Multicast DNS framework for Linux, including its features and how to use it to develop an application.


After lunch, former release manager Jeff Waugh introduced a change of pace and plugged in a Nintendo Wii to connect the dots between fun, easy-to-use devices and GNOME.


Conduit is software to synchronise applications, services and devices in GNOME. John Stowers demonstrated Conduit and how it can be used to synchronise all types of data, including files and Tomboy notes.


Finally, Monday ended with a GNOME Love Session, which took the form of a BoF session. Following suggestions on topics, attendees finally settled on the topic of discussing usability in GNOME. This gave a chance for many people, who considered themselves to be “just a user,” to speak rather than just listening to the GNOME-usuals.


Tuesday was action-packed. Chris Blizzard of Mozilla and OLPC fame gave a keynote for the conference proper. Then, after morning tea, Jono Bacon took the stand. Jono, who readers will know from LugRadio, spoke about Jokosher, the usability-focused, non-linear audio editor. During this updated version of the presentation Jono gave at GUADEC last year, he also took the time to demonstrate the latest Jokosher.


After Jono followed David Zeuthen, HAL-hacker extraordinaire. David spoke about fast user switching, multiseat, and allowing his girlfriend to use his laptop.


After lunch, artist and tango dancer, Andy Fitzsimon held a freeform session on GNOME rebranding, discussing if it was a good thing and whether it should be allowed.


James Andrewartha gave a quick presentation on, and then explained how to get started with jhautobuild. Ryan Lortie followed up with a brief five-minute overview of the new GNOME Applets API.

More Images

Java-GNOME’s Andrew Cowie came on after the break to show off Java-GNOME 4.0, the re-architecting of GNOME’s Java bindings that he is leading. In addition to discussing the design of Java-GNOME 4.0, he also demonstrated, live on stage, adding new API coverage.


Finally, to wrap it all up, Pete Ryland presented something he has been calling EGG, a framework layer on top of PyGTK to allow rapid development of applications.


About the author

Davyd Madeley is less cool than Kjartan Maraas, this is because he does not run his entire desktop session under valgrind. He is also less cool than Emmanuel Bassi, but at least he still has his SSH key. He wrote this biography while very tired, which is why it doesn’t actually tell you anything.

Discuss this story with other readers on the GNOME forums.