Category Archives: November 2009
Sumana Harihareswara provides a novice’s introduction to Telepathy, covering its goals, a guide to its architecture, platforms that use it, its future, and how to dive in.
It’s convenient to have a unified interface to different chat services & protocols: XMPP, MSN, Google Talk, AOL Instant Messenger, Bonjour Chat…. You may not think this is related, but when I want to work with someone on a document and we’re at different computers, it would be great to use my regular word processor, instead of having to load up a web browser with Google Docs. And I’d love to get to send cell phone text messages (SMS) in the same application with my other chats.
These are all aspects of real-time communication, and the Telepathy real-time communications framework is aiming to solve all these problems.
Pervasive real-time communication
The Telepathy project aims to give desktop applications (such as word processors, CAD programs, games, and jukeboxes) a way to painlessly integrate chat, SMS, and VoIP (voice over IP) telephony features. It’s a Freedesktop project, and it’s enabling new functionality on the desktop and on embedded devices.
Telepathy’s developers hope programmers will use Telepathy to improve your computer and cell phone and get rid of the annoyances I mentioned above, and create neat applications and services. Empathy is probably the most prominent Telepathy-based application. GNOME 2.28, Fedora 12, and Ubuntu 9.10 are shipping, or will ship, Empathy as their default chat program, giving developers on all those platforms access to the Telepathy framework.
I’ll give a brief overview of Telepathy, Empathy, and what they mean for you.
Here’s one way of viewing the Telepathy framework. It has three essential parts:
- a bunch of Connection Managers. Each handles the interaction with a protocol or set of protocols (such as XMPP, Google Talk, AOL Instant Messenger, and MSN).
- Mission Control, managing accounts and channels. For more details, see Danielle Madeley’s article, Telepathy, Empathy and Mission Control 5 in GNOME 2.28, in this issue
- the specification, telling all the parts how to interact via D-Bus
This design gives Telepathy a lot of flexibility. If a new interesting service comes along, like Facebook chat, we (or you!) can just write a new Connection Manager for it and bam, anything that uses Telepathy can now interact with it. Who knows what other interesting collaboration or communication networks might hook into Telepathy someday? (Sure, it would be nice if everyone just used XMPP. But users use a zillion different networks for voice/video/text chat, and won’t be stopping anytime soon. So it’s lovely to have an abstraction that provides developers and users with the features they need, so you don’t *have* to worry about the underlying communications network.)
D-Bus, Tubes, and wormholes
Another important aspect of Telepathy’s architecture that it’s built on D-Bus, the infrastructure that lets applications, frameworks, and low-level system components talk to each other. Telepathy Tubes takes advantage of this by enabling programs on different computers to talk to each other in terms of D-Bus. Prior to Tubes, the standardized D-Bus API was only useful inside a desktop session, so that one user’s desktop applications could talk to each other. As Telepathy developer Dafydd Harries explains:
Tubes come in two flavours: one looks like TCP, the other one is D-Bus. What D-Bus tubes do is make it so that programs on different computers can talk D-Bus to each other. So the D-Bus part is working on two levels. First, you use D-Bus to talk to the thing that gives you the tube. And then you use it to talk to the thing on the other end of the tube, once you’ve set it up….With Tubes, my copy of program X doesn’t need to care about the details of how it’s going to talk to your copy of program X.
So Tubes can act like a wormhole, not just between two different people’s computers, but between unassuming regular old apps on their desktops. For example, Tubes helped One Laptop Per Child get collaborative activities on the XO. On Sugar, you and a friend can collaborate on writing a paper together right in your word processor, or play a game against each other—without having to deal with a slow, limited web app in a web browser. One Google Summer of Code student used Telepathy to make Sudoku multiplayer. And in GNOME 2.28, Empathy makes it easy to share your screen via VNC. Check out Telepathy developer Guillaume Desmottes’s Gran Canaria Desktop Summit talk on how to use Tubes and Telepathy to make GNOME a more collaborative desktop.
Ripples in the ocean of mobile
Even regular folks who have never heard of GNOME are getting the benefit of Telepathy with (for example) the new N900 smartphone. One example is in the addressbook—it combines the different ways you can contact a person on the same screen (such as XMPP, SMS, Skype calls, GSM calls, etc), instead of forcing different flows for different ways of contacting people.
(Image copyright Marco Barisione)
Moblin, another Linux-based open source OS for mobile, also makes use of Telepathy for contacts integration. Empathy is the default chat client in Moblin, and Telepathy empowers its people panel integration.
Looking to the Future
The connection managers provide support for several protocols, with some managers more stable and featureful than others. I’d especially watch the improvement of telepathy-haze (based on Pidgin’s libpurple), telepathy-butterfly for MSN, and telepathy-yafono for SMS and other wireless modem functionality. yafono promises to bring functionality outside of the normal chat and VoIP stuff, so it’s fairly exciting.
GNOME Zeitgeist, with its focus on pervasive search and integration, could be a great framework for sharing ambient information and workflow—lightweight collaboration with faraway teammates. In development within Zeitgeist is Teamgeist, which would add to Zeitgeist the ability to share certain data and events with teammates via Telepathy Tubes and Multi-User Chat. Teamgeist is in the early design and implementation stages, but it’s clear that Telepathy will give Zeitgeist an easy way to plug into real-time communication functionality.
But why should GNOME get all the good stuff? (I know, I know, this is GNOME Journal, but there’s no need to get parochial.) KDE is getting in on the Telepathy action to get a unified messaging and voice/video framework throughout the desktop, and to add collaborative features to KDE applications. The NEPOMUK folks seem especially interested in ensuring that KDE’s use of Telepathy deals with metadata and metacontacts in a well-designed way.
How to dive in
Telepathy has a reference manual, a system overview, a mailing list, a wiki, and of course an IRC channel (#telepathy on Freenode). Empathy developers also use the Telepathy mailing list, and help users on #empathy on GIMPNet.
The Zeitgeist team hangs out on #zeitgeist on Freenode.
The Telepathy-in-KDE project’s in progress, so if you’re interested in Telepathy and want to dip your toe in KDE’s waters, check out the Telepathy Junior Jobs available for novice KDE developers.
And of course you’re welcome to join us in testing, documentation, development, packaging, and everything else.
About the Author
Sumana Harihareswara is a manager at Collabora, Ltd., which works rather a lot on Telepathy. She contributes to the project primarily via documentation, advice on IRC, bug triage, and nagging. Sumana has been using FLOSS for eleven years and evangelizes more than is good for her, including at her blog at http://harihareswara.net.
For many people, Telepathy is just an incredibly complex specification for implementing instant messaging clients. The truth is though, Telepathy is so much more. Telepathy allows programs on the desktop to use what we think of as Communications as a Service.
For many people, Telepathy is just an incredibly complex specification for implementing instant messaging clients. The truth is though, Telepathy is so much more. Telepathy allows programs on the desktop to use what we think of as Communications as a Service. Yes, it handles text and media communications and transfer files, but it can also be used for so much more, like transferring information between applications for collaboration over the internet. Communications as a Service means that communication is no longer the purview of one monolithic communications application and any application on the desktop can access the same set of shared communications accounts. This means communication is now possible all over the desktop. This has many exciting possibilities: opening text chat from Evolution, sending files to other users via Nautilus, collaboration with colleagues via Telepathy Tubes. We’ve only just begun to explore what’s possible here. This article talks about some of the features Telepathy offers in GNOME 2.28. For more information on Telepathy itself, see the Telepathy Overview article in this edition by Sumana Harihareswara.
Mission Control 5
One of the most exciting, yet under-hyped features in GNOME 2.28 is the transition to Mission Control version 5. Mission Control forms a core, and until recently absent, piece of the Telepathy infrastructure. It allows application developers to provide pluggable clients to handle all kinds of collaboration: VNC between contacts (available in GNOME 2.28), online gaming, collaborative document editing, event sharing (e.g. Zeitgeist). What exactly does Mission Control do you ask? Mission Control provides two important components of the Telepathy API: the Account Manager and the Channel Dispatcher. The Account Manager does what it says on the tin; it provides storage and retrieval for the user’s communication accounts (e.g. her XMPP account, MSN account, Google Talk account, Facebook chat account, etc.). It is also responsible for managing the presence (e.g. Available, Away, Busy, Out to Lunch) for each account (which may be individually different) and initiating the connection for each account via the respective Connection Managers (a Connection Manager is responsible for the connection and abstraction of a given protocol). The Channel Dispatcher is responsible for the handling of communications channels, for instance text, Voice-over-IP, file transfer or Telepathy Tubes. When a channel is created by a Connection Manager, the Channel Dispatcher is responsible for finding an application that can handle the channel (known as a Client). Empathy is an example of a Telepathy Client that can handle incoming text, voice/video and file transfer channels. As well as receiving incoming channels, the Channel Dispatcher can also be used to find a suitable client for a locally-initiated channel. For instance, Evolution might request a text channel to a certain user. The Channel Dispatcher can then dispatch that Channel to Empathy to carry out the text chat. There are three kinds of Telepathy Clients: Observers, Approvers and Handlers, although a single application might implement all three. Clients are either registered dynamically by the application while the application is running, or can be registered via a ”.client” file, so that the Channel Dispatcher can launch the Client when required. Each Client provides a list of channel types it is interested in (e.g. text, file transfer, streamed media, Tubes of a given type) via a D-Bus property, and optionally as part of the .client file (for clients that activate on demand). Observers are passive clients that simply observe what’s happening on a channel. An Observer might be used to implement logging of text chat, progress of file-transfer, list in-progress chats, or notify the user of incoming messages. Observers can be used to make some requests to a channel, for instance cancelling a file transfer. Any number of Observers are allowed to observe a channel, all running or activatable Observers are informed of incoming channels. Approvers are responsible for approving an incoming channel, either implicitly (as might be the case for text chat) or by asking the user if she wishes to receive the channel (e.g. for a VoIP call, file transfer or tube). The Approver can also recommend a Handler. All running or activatable Approvers are queried about an incoming channel, so ideally only one approver per channel type is available and should be provided by the desktop. Finally, there are the Handlers, the type of Telepathy Client that most developers will create. These are the applications that will handle the channel. Only one Handler is chosen for a given channel, which can be recommended by the Approver or chosen by the Channel Dispatcher. A typical handler might be the chat interface for a text channel, a VoIP UI or a Tube application. GNOME’s Empathy client provides Handlers for text, VoIP and file transfer channels.
Tubes and MC5
The most significant feature of this work for GNOME is enabling applications to utilise Telepathy Tubes. In Telepathy, we think of Tubes as contact-to-contact networking. Tubes enable one-to-one, one-to-many or many-to-many communication between contacts using either network sockets (stream tubes) or a private D-Bus bus (D-Bus tubes). This allows applications to support collaboration between users, with a minimal amount of effort on the part of both application developers and the end-user. Application developers can now focus on their application protocols, without having to worry about networking, firewall traversal or service discovery. End users no longer have to configure collaboration accounts, share IP addresses or forward ports on their firewalls. Here’s how it works. An application registers itself with the Channel Dispatcher indicating that it handles a certain type of tube. This Tube name is then advertised as a capability to users subscribed to your presence. If I want to play Sudoku against you, my Sudoku client requests a list of all my contacts who advertise the Sudoku Tube capability. The Tube is offered to the contact I select. Your Channel Dispatcher receives this channel and passes it to the Approver which displays a dialog asking if you would like to play a game of Sudoku against me. Assuming you approve the channel, the Channel Dispatcher then passes the channel to the recommended Handler (the game client) which can then accept the Tube. At this point our two applications are now connected via the Internet. [The Telepathy Connection Manager takes care of the precise method of connection, utilising whatever technologies are available with the given communications protocol.]
Empathy in GNOME 2.28 and beyond
Empathy in GNOME 2.28 has been reworked to take advantage of Mission Control 5, and now implements Handlers for text, file transfer and VoIP channels (it also provides an Observer which it uses to log text conversations). However, Empathy does not yet request outgoing channels via the Channel Dispatcher, which means that it’s not yet possible to replace a given Handler and have the channel launched from the Empathy roster. This will be fixed for Empathy 2.30, which will create a complete functional disassociation between each component of Empathy. This will allow Empathy to operate as a series of modular components and allow any individual component to be replaced (e.g. allowing for an improved multi-user chat interface). Empathy’s accounts configuration UI can become a configuration pane that talks directly with Mission Control’s Account Manager. Control of online presence, also handled via the Account Manager, can be integrated with the GNOME Shell or another desktop component. A full roadmap of Empathy related improvements is available at http://live.gnome.org/Empathy/Roadmap/Roadmap230. A telepathy-gtk library, complementing telepathy-glib, which provides widgets for Telepathy-related actions that applications are likely to need, for example a contact selector, is planned for the GNOME 2.29 development cycle. This cycle will also include further development to telepathy-glib, to make more common tasks easier (such as implementing a Tube Handler). Work is now taking place to look at how Telepathy might integrate into the GNOME Shell.
Metacontacts: The Missing Component
Telepathy provides no service supporting the idea of “metacontacts”, where individual contacts (and email accounts, etc.) provided by different protocols are unified into the concept of a single person. For example, you might have contacts in your roster for email@example.com, firstname.lastname@example.org and email@example.com, but so far there is no service responsible for storing that these are the same person. One solution that has been proposed that these relationships be stored in Tracker using the Nepomuk people ontology. Although desired in Empathy, this is somewhat out of scope for Telepathy itself, because it covers more than just information handled by Telepathy (e.g. email addresses, social networking accounts, etc.). It is, however, a problem of interest to Telepathy developers, and so we’re interested to hear from people who want to work to solve this problem.
Would You Like To Know More?
For developers who want to get started writing a Telepathy Client (e.g. using Telepathy Tubes in your application), Telepathy provides GLib’ish bindings via the library telepathy-glib. The latest version of these bindings provide classes to simplify dealing with the Account Manager. Although Telepathy is a D-Bus API, and thus can be used with any D-Bus library, this API is quite low-level. The bindings provide useful utility functions and classes that take the heavily lifting out of commonly repeated Telepathy operations. Note: there are two older libraries: libtelepathy and libmissioncontrol, but these libraries are very deprecated and should never ever be used. There is also a work-in-progress Telepathy book (http://people.collabora.co.uk/~danni/telepathy-book/), which includes numerous examples of implementing Telepathy applications. More information is also available at the Telepathy website, mailing listand IRC channel (freenode/#telepathy).
About The Author
Danielle Madeley is an Australian software developer working for Collabora Ltd. The first Linux distribution she used was RedHat 6.0. She enjoys taking photographs, playing the saxophone and eating vegan food. Her favourite colour is purple, but it used to be green.
As the GNOME Project gears up to kick off a new Outreach Program for Women (OPW), Marina Zhurakhinskaya and Hanna Wallach look back at the Women’s Summer Outreach Program (WSOP) from 2006. Marina follows up with the participants to see what they learned and how OPW can benefit from past experience.
The GNOME community is determined to increase women’s participation in the project. Specifically, the community would like to increase the visibility of existing female contributors and create a support system for encouraging women’s participation.
The first women’s outreach program (WSOP 2006) was run in the summer of 2006 and was motivated by the fact that GNOME received 181 applications for the 2006 Google Summer of Code (GSoC) program, yet .none were from women.
Hanna Wallach and Chris Ball, who organized the outreach program, found that the following steps resulted in around 100 qualified applicants:
- Creating a program specifically targeted at women
- Changing the language advertising the program from more Google’s more competitive “prove you are the best” style to a more collaborative “gain experience developing Linux desktop applications in collaboration with open source developers” style
- Making use of wide-spread, word-of-mouth advertising via supporters at various colleges and universities
They also noted that the success of the program was highly dependent on finding mentors committed to following through with their mentorship responsibilities.
Federico Mena-Quintero, who was one of the participating mentors, created a guide about how to be a good mentor based on his experience with the women’s outreach program and GSoC. This guide contains important advice for anyone interested in being a mentor in one of these programs, including introducing your student to other people in the GNOME community and taking time every week to test your student’s code or otherwise evaluate their work and provide feedback.
The GNOME community would like to ensure a consistent, on-going effort to engage more women with the project and is therefore organizing a new Outreach Program for Women that will encourage women’s participation throughout the year and will create internship opportunities in the summer. Creating better resources for all newcomers will be an integral part of this program. However, having materials specifically targetted at women will result in a wider spread of information about how exciting, varied and valuable work on GNOME can be. Ultimately, the goal of the program is not only to recruit female applicants for the OPW internships, but to recruit them for the GSoC GNOME projects as well.
We are currently raising money for the OPW internships to make this part of the program possible. The GNOME women mailing list is the main communication channel for updates about the program, so feel free to sign up for it if you are interested in participating or helping with the program in any way.
We asked the six WSOP 2006 participants to share their experiences with the program and their advice for the program organizers, mentors, and participants. In doing this, we learned that they all stayed in technical professions, are big users and proponents of FOSS, and have great things to say about their mentors and the GNOME community. Most of them keep technical blogs. Unfortunately, many of them did not have their work during WSOP incorporated into GNOME (which is common in GSoC as well) and did not have time to continue contributing to FOSS due to busy school and work schedules.
WSOP 2006 was organized in about a month, after the 2006 GSoC applications were received. In contrast, the new program has allocated more time for resource preparation and the selection process. We are already looking for mentors for the program and would like to have online bootcamps for the participating projects before the application period. This will enable applicants to familiarize themselves with the projects and will also provide the mentors with applicant contributions to evaluate during the selection process. Unlike WSOP 2006, the new program will also include non-programming projects such as graphics design, interaction design, documentation, and marketing. We are also considering letting participants work as part of the team starting with smaller contributions, progressing to larger ones, rather than working on stand-alone projects. This is more similar to the way companies run their internship programs and will ensure that contributions get incorporated into GNOME throughout the summer. Finally, we will offer support for the participants in the #gnome-women IRC channel on irc.gnome.org and will include the participants’ blogs on Planet GNOME with a special logo, as is already done for the GSoC participants.
Here are the responses from the WSOP 2006 participants. They all share some great insights!
Who are you?
Fernanda Foertter: I was born in Brazil, moved to the US 20 years ago. I have a BS in Physics and an MS in Materials Engineering. I started learning to program on an Apple ][ e back in Middle school, and later using Pascal!! Then more seriously for scientific purposes when I was working in the High Energy Physics Lab. Later moved onto HPC working in computational chemistry during my MS.
Monia Ghobadi: Currently, I’m a third year PhD student at University of Toronto. At the time of WSOP I was doing my masters at University of Victoria.
Cecilia Gonzalez-Alvarez: I am a 25 year-old girl from the Canary Islands, living for 7 years in Barcelona. I’ve studied Computer Engineering at the Technical University of Catalonia and now I’m enrolled on a PhD program at the same university.
Ümran Kamar: I am working as Computer engineer and study Aeronautical Engineering as Master degree.
Clare So: I am a software developer now living in Waterloo, Ontario, Canada. I completed my BSc and MSc in Computer Science at The University of Western Ontario, Canada. I attempted PhD in Computer Science at McMaster University but left without finishing the degree. Other than computers, I am also interested in classical music. I have been singing in various local choirs for the last 10 years.
Maria Soler: I come from Barcelona but I’m currently living in Denmark. I’ve been in Maths university (not the whole thing but enough to get some interesting ideas), in Electronic engineering school and now studying further into distributed and real time systems.
What did you accomplish as part of your WSOP project. Who was your mentor? Did your work get incorporated into the module you worked on?
Fernanda Foertter: I started graduate school that very summer so WSOP did more for me learning than I was able to finish. I learned a lot about GUI programming and helped me land a job after grad school! Chris Ball was my mentor and he was a great mentor! Unfortunately I couldn’t finish my work in time, so it did not get incorporated into the module.
Monia Ghobadi: The project that I worked on was called Gnome-Screen: Integration of Gnome Terminal and GNU screen. Behdad Esfahbod and Chris Ball were my two incredibly cool mentors. Unfortunately my work did not get incorporated into the module yet. I keep giving people my patch here and there and I had a chat with Behdad on resuming my work.
Cecilia Gonzalez-Alvarez: My project was the optimization of the switch of components (mail, contacts, calendar, tasks, memos) in Evolution. The time of switching increased exponentially with the number of switches done (almost 2 seconds after 200 switches). I profiled the application, analyzed the code and detected and solved the bug responsible of that behavior. My mentor was Federico Mena-Quintero. I think my work got incorporated into the module… Federico did the update on the CVS.
Ümran Kamar: I worked at developing Mozilla plug-in for Evince pdf reader project. My mentor was Ronald S. Bultje. I don’t know if my work got incorporated into the module.
Clare So: I helped my mentor designing a cut/paste/selection mechanism in his existing math expression viewer. My mentor was Luca Padovani from Italy. Unfortunately, my work did not get incorporated into the module.
Maria Soler: In my WSOP project I was supposed to enable synchronization in Tomboy. I didn’t get that far, but I touched some Mono libraries on the way, although I’m not sure if the changes got into the modules. My mentor was Alex Graveley.
What were your experiences with your mentor and the community?
Fernanda Foertter: Really positive! My mentor was very knowledgeable and patient and the community is really great.
Monia Ghobadi: Overall, it was an amazing experience. I had the opportunity of attending OLS and meeting my mentors as well as members of the community which I find amazing. From the IRC chat helps to the comments on my blog, I find the community one of the most interesting parts of GNOME.
Cecilia Gonzalez-Alvarez: My mentor was great, well organized and always willing to help me if I got stuck, specially in the first part of the project, the building and configuration of the working environment.
Ümran Kamar: Community was pretty good, especially Chris Ball helped me so much.
Clare So: I was surprised that no one told me to “RTFM” when I did not understand something. My mentor was patient. In addition, I enjoyed hanging out with some local GNOME users and developers in the Toronto area.
Maria Soler: I didn’t have enough contact with my mentor during the project. I was too proud to ask for help and approval, and he didn’t press me much. The time zone difference didn’t help either. I got to talk to some other developers by mail and IRC and I got a very good impression about working in this community.
What did you learn about GNOME and FOSS from your participation in the program?
Fernanda Foertter: The great way the community keeps bringing great open-sourced project. I became a much bigger advocate for open source and not just a user.
Monia Ghobadi: I learnt a lot. WSOP had a big impact on my vision towards open source.
Cecilia Gonzalez-Alvarez: I found a big community of people that really appreciate new helping hands.
Ümran Kamar: I learned GTK programming.
Clare So: Developing for GNOME is a great way to play with your ideas and get constructive feedback. It is a good way to see how a real piece of software can be designed, written and maintained.
Maria Soler: I was at GUADEC just before starting the WSOP, and already there I could see how many great and enthusiastic people this community has. And that makes a great GNOME desktop. And FOSS… I became a bigger enthusiast myself!
Did you contribute to GNOME or any other FOSS project since 2006?
Fernanda Foertter: Mostly as a alpha/beta tester. I’m hoping to get back to coding now that I left grad school and started a job.
Monia Ghobadi: Unfortunately no as I have been busy with school.
Cecilia Gonzalez-Alvarez: Unfortunately I didn’t have the time to participate in more projects.
Ümran Kamar: Yes, I was contributing to Pardus Linux distribution before and after the program by testing, reporting bugs, and writing HOWTOs.
Clare So: My involvement in GNOME has been limited since working in a full-time job. Sometimes I browse the Ubuntu questions posted in Launchpad and see if I can answer any. It’s a great way to encourage others to use free software.
Maria Soler: I didn’t keep contributing. I both work and study, with programming, and I have not much free time. I hope I can start again when I’m done with my studies.
Do you use any FOSS technologies now?
Fernanda Foertter: YES! I use FOSS at home and encourage my newest employer to use OSS at work. I definitely evangelize more since WSOP because I understand the model better. At work I use Ubuntu, Scite, Mono, all sorts of compilers… you name it at work for coding. My netbook runs Moblin, my home computer runs Ubuntu. Only my work laptop is a Mac, and filled with open source goodness there too.
Monia Ghobadi: I use Ubuntu/Google Chrome/Mozilla Thunderbird and of course GNU screen and lot and lots of other things at home and school.
Cecilia Gonzalez-Alvarez: Always. I’m a 100% Linux supporter and try to spread FOSS. I use Arch Linux with GNOME desktop at home and OpenSuse with GNOME desktop at work. I also have an Android phone.
Ümran Kamar: I use Pardus operating system and open-office, multimedia and gaming tools.
Clare So: I am an Ubuntu user.
Maria Soler: I use only Ubuntu in my personal computer and I try to use as many FOSS application as I can at work; Pidgin as IM application, Dia for diagrams, etc.
What do you work on now?
Fernanda Foertter: I’m a scientific programmer for a genetic company. I code anything from FORTRAN to C/C++/VB/C# (which I started to learn during WSOP).
Monia Ghobadi: Right now, I’m doing an internship at Google. At school I’m working on router buffer sizing and transport protocols in the Internet.
Cecilia Gonzalez-Alvarez: Trying to deal with my PhD thesis… something about the automatic generation of hardware accelerators for bioinformatics applications. Also in my work I use FOSS technologies, like the LLVM compiler, GCC, all running on Linux.
Ümran Kamar: I am studying on aeronautics.
Clare So: Nothing particular to FOSS technologies. I am working as a software developer at Maplesoft, maker of Maple computer algebra system.
Maria Soler: I work on finishing my Master’s Degree and in the meanwhile I get paid for working on smart metering systems (electricity, heat, water, etc.).
What advice do you have for the new program organizers, mentors, and participants?
Fernanda Foertter: To create a project plan and timeline, with perhaps a way for the participants to regularly communicate throughout their learning experience. The mentoring is great, so change nothing!
Monia Ghobadi: I think as interesting as a remote program is, it is not the most effective way to get people involved. I would suggest planning a summer school or even better on-site internships instead of two month remote work.
Cecilia Gonzalez-Alvarez: It would be great if there were more continuity with the program (it has been a while from 2006).
Ümran Kamar: The objective of the program should be getting new people into the community. Mentors can keep being awesome.
Clare So: For the organizers and mentors, I would like to say that one advertising campaign would not fix the gender imbalance in FOSS community. Every FOSS member must promote a welcoming atmosphere to all people who may be interested in FOSS. For potential participants, you may be surprised in what you can do in a real piece of software. The GNOME community is more friendly than you think.
Maria Soler: I would advice the mentors to keep an eye on their project participants, and the students to not be shy, not too proud, not afraid of what the mentor would say… ask and talk!
Your WSOP project blog or write-up, and your current blog or web page?
Fernanda Foertter: My current blog project is http://hpcprogrammer.com
Monia Ghobadi: http://monia.wordpress.com
Cecilia Gonzalez-Alvarez: Here is the project blog: http://m3gumi.wordpress.com and here is the project report that contains the main points of what I did. Currently I don’t maintain any personal webpage or blog.
Ümran Kamar: My blog is http://www.handlet.blogspot.com and it has one entry about the WSOP project: http://handlet.blogspot.com/2006/07/wsop-first-screen-shot-of-evince_20.html
Clare So: My blog is found in http://lacampanella.wordpress.com. It contains some progress reports on the WSOP project.
Maria Soler: I don’t have the blog I had when I was doing the WSOP… the server was shut down long time ago and I didn’t recover my data. Here is my current one: http://mariadelsrinxols.blogspot.com
About the Authors
Hanna Wallach is a senior postdoctoral research associate at the University of Massachusetts Amherst, working on Bayesian inference for machine learning problems. In her not-so-spare time, Hanna has contributed to both GNOME and Debian, and is involved in several projects that encourage women to participate in free software development. Her favourite food is kale.
Marina Zhurakhinskaya is a Senior Software Engineer working on the new shiny GNOME Shell code on the desktop team at Red Hat. She is particularly interested in making sure that GNOME desktop is intuitive for the users and well-documented for the contributors. Outside of work, she likes to hang out with friends and family, travel, listen to audio books, and read reviews on Yelp, TripAdvisor, and Amazon.
Cathy Malmrose gives a glimpse into a project where seven year old girls build desktops with Ubuntu for their grandparents.
One early spring day as we were walking home from the bakery on the corner, we passed by a neighbor and struck up a conversation. He complained about his desktop being constantly attacked by viruses. We suggested Ubuntu. A professional man in his 50s, he said he wanted to try installing a Linux distribution on his desktop but that, “it looks too complicated. I probably couldn’t install Ubuntu. I don’t want the hassle.”
My little five year old daughter had been snuggled in my arms while I was talking to this neighbor. She had been listening closely. When we got home, she said, “Mom, I can install Ubuntu. I bet I can. Can I try? Can I try?”
As a mother who wants to foster her children’s interests in all things technical and scientific, I dropped the loaf of french bread and turned on a nearby desktop. I did a quick back-up and wiped the system. I handed my daughter Anna an install CD and said, “Here you go.”
Then I walked away.
From the kitchen, I watched the install unfold. She insert the CD. She read what she could on-screen and pressed Enter a lot. When she couldn’t read something, she called her brother who was only one year older, but who could read a few more words than she could. She yelled, “Jake! Come here and tell me what this says!” Together they figured out, “Hey, if you just press Enter, it usually works out fine.”
With a little bit of help from her six year old brother, Anna successfully installed Ubuntu on a desktop. When she was done, I came in and asked, while trying to squelch my pride, “So, sweetie, how did it go?”
Anna’s reply, “Easy baceasy! That old foggy is just being silly. I can install Ubuntu, so he can install it too.”
We have had many similar experiences of successful interaction between little kids and software that is well built. The most recent experience was sparked when we noticed far too many small form factor desktops accumulating in our aptly named “We don’t want it; you want it?” pile at our computer shop, ZaReason. We called a few friends to clear out some hardware and we set up two projects to clean out a few of the nicest desktops.
Recently, my dad has been putting in the hours to preserve family home videos, and called me one day asking for advice for which new desktop he could buy. Since I had been staring down a pile of excess, but still quite usable hardware, I asked my dad, “Hey, can you wait a few weeks and your granddaughter will build you a desktop that will be ideal for video editing?” The reply was a supportive, loving, “Sure!” It was such a pleasing thought to me that my parents would be the only ones on their block with a desktop built by their little granddaughter. I hoped they would have many good laughs about it with their friends.
A little background: My parents are in the generation where we hear questions such as “Where’s the On button?” and, “Oh, those newfangled computers are just too complicated.” Still, my parents are gutsy enough and smart enough to try new things. They also have endurance and persistence. They have had a few brief introductions to Linux, but none of them stellar.
Since there were plenty of small form factor desktop cases and plenty of components, I asked Anna if she wanted to have a building party with a friend. One Saturday, her friend Tora came to our little shop and the dads worked alongside their daughters with each father-daughter team assembling their own desktop. The girls had an interesting way of building. It went like this:
Anna finds two screwdrivers, hands one to Tora.
They both look for something to unscrew. They get the screws off, then wiggle the case off. The dads have to help with sliding the case off.
The girls run around for a few minutes talking about how, “I opened it up and we can see its guts!” After they calmed down again, they came back to the table and asked, “What’s next?”
The dads, being the awesome teachers they are, said, “I don’t know. What do you think is next?”
The girls put in the memory sticks, then did somersaults.
They did the goo on their CPUs, seated them, then spun around on the office chairs until they were sickeningly dizzy.
They put their fans in place, then ran around for a bit.
Tora had question after question. “What’s this? What does it do? Why do we need this? Why is that metal thingy there? Is it ok if I touch these spikies?”
The most interesting aspect of the build was that the girls seemed to have an innate understanding of the hardware that was a level higher than what I had anticipated. They had so much fun building these desktops that they decided to keep them for themselves.
We invited over another friend, Lizzie, for another build session, hoping that this time the desktop would go to Grandma and Grandpa. The build session was similar except that Lizzie was focused and did not take breaks between components. She talked the entire time. The girls also focused on only one computer at a time. Lizzie built hers first with Anna helping and watching, then Anna built hers with Lizzie helping and watching.
These two girls’ determined focus was balanced by a sweet team-building camaraderie. They did each build on a child-height blue IKEA table in the middle of our shop with a massive overhead skylight providing sunlight on their work station. One parent was sitting nearby and another was working over on a different table. The girls worked with a minimal amount of adult direction.
I was in the upper level loft helping my eldest son with his college application, so I had a bird’s eye view of the experience. I could hear them saying, “Here Lizzie… yeah… you got it!” and “Anna, do you have an extra screw for this? The case was missing one.” Every time I peeked over the loft ledge, I could see them sitting beside each other, working as partners. It wasn’t like they were drawing together or doing other types of work together. They were interacting as if they were co-painting a canvas together.
For both builds, the girls lost interest during the software install. It was too easy. They went on to playing and running around the shop. For each of the builds, a fully functional desktop was “born” to live another full life in a new home. For all three girls, they now understand that if there is a problem with their desktop, they can open it up and replace a part. They are empowered to fix it themselves.
We have enjoyed the delightful payoff of providing this type of opportunity for people of all ages. When you open a desktop, you realize that the internals are not scary. You have a greater appreciation for keeping the components healthy. Try opening a system that has been working without being cleaned for three or four years and you’ll find enough dust to make you shudder. Once you see that the insides need care, just like the insides of a human body, an automobile, even the inside of a house, you have a greater appreciation for the functionality of the desktop.
As I write this article, my daughter is home sick. She is watching Pink Panther on Hulu, using a desktop that has a failing hard drive. Several times, she started up the system only to see “Disk Boot Failure”. Soon, she will probably ask, “Mom, what does this mean?” and rather than rebooting until it starts properly, she will think, “Hey, I can replace the hard drive. Myself.” I am curious to see how long it takes before she seeks out a screwdriver and asks, “Hey, mom, do you have an extra hard drive I can use?”
There are many natural ways to take the scary factor out of computing. The more we can present various Linux distributions as being “easy” and “workable”, the more we can reduce stress in computing with those we love.
About the Author
Cathy Malmrose is CEO of ZaReason.com, a Linux-only hardware company based in Berkeley, CA, USA. With vibrant local Linux User Groups, Cathy is often involved in charitable projects through a non-profit, Partimus.org. In her spare time, Cathy enjoys traveling, seeing how free software is developing internationally. Her dream is to have little shops all over the world.
>Leslie Hawthorn, leader of the Google Summer of Code, talks about GSoC, mentoring, the GNOME Advisory Board and GNOME Foundation, women’s participation in FOSS, and her advice to new contributors.
Leslie Hawthorn held various roles at Google before joining the Open Source Programs Office in March 2006. Her first project after joining the team was spinning up Google Summer of Code 2006 and she has managed the program ever since. She also conceived, launched and managed the Google Highly Open Participation Contest, an initiative inspired by GSoC that helps pre-university students get involved with all aspects of open source development. She represents Google on the GNOME Advisory Board. Mentoring in open source communities is one of her personal passions, along with humanitarian uses for open source software. She loves to cook, read and can occasionally be found pining for illuminated manuscripts. She also likes to think of herself as a superb filker. She can be found on identi.ca (@lh) or at http://www.hawthornlandings.org.
This interview took place in late October 2009.
Hi, Leslie. You’ve been involved in the free software world for a while now, most notably with Google Summer of Code. What’s the goal behind Google Summer of Code?
The program has several goals:
- Get more open source code written and released for the benefit of all.
- Inspire young developers to begin participating in open source development.
- Help open source projects identify and bring in new developers.
- Provide students the opportunity to do work related to their academic pursuits during the summer: “flip bits, not burgers”.
- Give students more exposure to real-world software development scenarios (e.g., distributed development and version control, software licensing issues and mailing list etiquette).
We’ve been incredibly successful in achieving each of these goals. Most projects report gaining at least one new committer from among their GSoC students and many students go on to mentor for the program. We repeatedly hear from students that their participation in GSoC helped them land the job of their dreams and I have heard from one mentor that his first interview question to candidates is “Have you been a Google Summer of Code student?” We estimate that the program has produced more than 6 million lines of Free and Open Source code over the past five years, all available for anyone to use free of charge.
How many students have been introduced to free software through Google Summer of Code and GHOP?
We’ve had more than 3,300 students successfully complete their projects over the past five years. We’ve only run the Google Highly Open Participation Contest, a companion program to GSoC to help get pre-university students involved in Open Source, once so far. Our first foray with GHOP was very successful, as well – more than 350 students in 40 countries completed over 1,000 bite-sized chunks of work in areas like coding, documentation, user experience research and testing in just a two-month period.
What has surprised you the most about GSoC?
The enthusiasm for the program never ceases to amaze me. Sure, I think it’s cool because it’s my day job and personal passion. But I constantly get emails from both mentors and students telling me that participating in GSoC changed their lives, transformed their communities to be more open to new contributors and helped them realize where they could be more helpful to the overall world of Free and Open Source software. I feel privileged that I get to spend my time working to help empower such an amazing group of people.
One of the things that surprised the GNOME project a few years ago was that we didn’t get any women applying for our projects through Google Summer of Code, so we created the Women’s Outreach Program, which Google sponsored. How do women fare overall in GSoC?
I feel like the women participants in the program get a great deal of support from the mentoring organizations and many projects specifically attempt to recruit women when selecting GSoC students. One of GSoC’s greatest success stories, Angela Byron, joined the Drupal project as a brand new contributor in 2005 and is now the maintainer of Drupal 7. The Systers project also participated for the first time this year and I think their presence really helped us to show the community in a tangible way that we welcome and encourage women to join the Summer of Code community. I also want to give a shout out to all of our women mentors, as there are many of them and they actively maintain a presence in our program IRC channel (#gsoc on Freenode) so women know they are not alone and have role models for their participation in GSoC and FOSS.
You recently attended the Women’s Free Software Summit. What can we expect to see from that?
We’re working on some great projects, like outreach to conference organizers to help them recruit more female speakers and a Couch Surfing like network for women so they have fewer economic barriers to attending FOSS conferences. This group has had some of the most productive conversations I’ve seen around diversity in FOSS and one of the express goals is to provide solutions, not just complaints. I am proud to volunteer my time here and would encourage any like-minded souls to join us for the monthly IRC meeting in #glofs on Freenode (every 4th Tuesday at 18:30 UTC).
You sit on the GNOME Advisory Board; what do you hope to accomplish in that role?
I’m excited to sit on the Advisory Board since it helps me learn more about how a successful FOSS non-profit runs and to network with other business folks who are working in FOSS. I’m honored to serve and provide expertise in any area where I can, but I primarily hope to help the Foundation’s marketing and outreach efforts, current and future.
What do you hope to see the GNOME Foundation accomplish in the next couple of years?
I know the Foundation has been working on another Women’s Program and I’m very pleased to see that happening in the community once again. I know that GNOME has had incredible success with focused hackfests and I’m excited about the first marketing team sprint, which will take place in the next few weeks in Chicago. I’d also like to see more work done to expand the GNOME Love program, as any efforts that help bring more newbies into FOSS and contributing to GNOME would be useful to the community.
You’ve had a successful career, launched some amazingly successful programs – GSoC and GHOP – as well as sit on advisory boards and steering committees like the GNOME Advisory Board and the HFOSS Steering Committee. What advice would you offer to a young person looking to create a career in free software?
1) Remember when you receive criticism, even when it is harshly worded, to look for the good in that criticism and use it to improve yourself. The FOSS world is sometimes a blunt place and it can be easy to get discouraged. Recall that contributors to FOSS are often volunteers and their time is extremely limited, so taking the time to send criticism means your work is valued and they see potential in your contributions and your ability to make your work even better. If you do not come from the free software world, check out Randy Pausch’s Last Lecture – there’s a great bit in there where he talks about being harshly criticized by his football coach. This anecdote is a great illustration of how things work in the FOSS world with respect to criticism.
2) Focus on your greatest passions. There are many areas in FOSS to contribute, so concentrate on one or two areas at first. It’s natural to move on to other projects later, so dip a toe in before taking a swim in the deep blue ocean.
3) Look for answers on your own at first, but don’t be afraid to ask for help. When you do ask for help, be sure to let folks know where you’ve already looked to find your answer. This ensures that they don’t send you back to a resource that did not solve your problem and, most importantly, shows that you value their time since you tried to solve your own problem first. Some folks recommend Eric Raymond’s Asking Questions the Smart Way. My rule of thumb is that I ask for help if I cannot figure out how to solve my problem within 30 minutes.
4) Have fun. While you are busy having fun and making cool stuff, remember that the code you write helps businesses run, non-profits care for your fellow people, governments recover from disasters, etc. Doing the right thing was never so cool or enjoyable as in FOSS.
About the Interviewer
Stormy Peters is the Executive Director of the GNOME Foundation.
Diana Katherine Horqque examines the latest Epiphany web browser that runs exclusively on GNOME. If you haven’t given Epiphany a try lately, it might be worth your time. Epiphany is a lightweight and simple-to-use browser for when you just want to get things done.
Epiphany totally rocks
I started using Epiphany at the same time I entered into the world of Ubuntu. It is also very probable that my delight in the GNOME web browser is because it is a transcendent part of my first approach to a project of Free Software. And I’m aware of how lucky I am, because all the process involved with my first experience with Epiphany was very pleasant. I became familiar with using the application with little effort, and find great benefits from Epiphany that I could not enjoy in other browsers.
Reinout van Schouwen mentions in his essay Epiphany celebrates its second birthday! that although “Firefox enjoys massive popularity among GNU/Linux users, so much that even some distro vendors have opted to have Firefox as the default browser on their GNOME desktop, Epiphany’s developers consider this situation as an incentive to make Epiphany totally rock.” And they always have the perspective of what a GNOME web browser should be; all their reflections and actions are focused on this vision.
The essence is simplicity in use
Epiphany’s Manifesto refers to the Simplicity: “Epiphany aims to utilize the simplest interface possible for a browser. (…) Epiphany addresses simplicity with a small browser designed for the web.”
The essence of Epiphany is, obviously, browsing the web. And I relish the sweetness of their simplicity in something as simple as looking for some information. Just type the URL in the location bar and hit enter.
“The point of a good program is to do something specific and do it well.” Havoc Pennington
You think of me
The other interesting way to think of Epiphany is that the developers target non-technical users by design, and I consider myself to be apart of this group. So, they think that technical details should not be exposed in the interface and, for me, this is a good idea.
I consider Epiphany the expression of a good user interface and I would like to refer to Havoc Pennington in his essay about the Good User Interface: clean, simple, consistent productive. For me, the beauty, the truth and the glory of a interface is not in a “lot of features, or alternatively a lot of snazzy graphics”. They are not the heart of a good user interface.
The matter of preferences and integration
As I read in the Epiphany Manifesto, Havoc’s “main goal is to be integrated with the GNOME desktop.” For me, it’s interesting that the first priority of people who think and reflect on Epiphany and are behind its development is the exclusive integration with GNOME, and that they don’t feel compelled to make Epiphany usable outside of GNOME. This argument stems from the intuition that “the union of all features anyone’s ever seen in any equivalent application on any other historical platform” is not necessarily the path indicated to a good UI.
Havoc believes that “more preferences means fewer real features, and more bugs” and my intuition and experience tell me he is right. The Manifesto also mentions that developers work with this concept and considers: “at some point the existence of preferences means that everyone must configure their desktop; while ideally preferences are optional and the default behavior is reasonable without intervention. (…) Reflection should focus on when a preference should exist, and when it should not.”
The way I found the sweetness
Today, many browsers have a tabbed interface, and have developers who realized that it is much more effective to use a tabbed interface than separate windows to display multiple pages. However, I am inclined to believe that this feature was inherent in Epiphany since the beginning: Ctrl-T opens a new tab, Ctrl-W closes the tab, and Ctrl-Tab and Ctrl-Shift-Tab moves back and forth between the tabs.
To find links that you’ve already visited on a website is very simple. You just need to type the first letter(s) of a link and matches are highlighted. This feature is thanks to the Gecko technology embedded in Epiphany.
Those times when Epiphany crashes or when I have to restart my GNOME session while Epiphany was open, I, fortunately, can restore to my previous state.
The glorious parameter p
Thanks to Epiphany I can work with two sessions of different users within GMail. Before using this parameter, it was necessary log out of my GMail session to log into my other user. Since I constantly manage two separate accounts, the personal account and the account for volunteering, this feature is wonderful.
Running “epiphany -p” opens a “private” instance of Epiphany which works with a different window. This command won’t terminate until the browser is actually closed. This separate window is perfect for guest users that are using your computer (because you kindly lent them a few minutes) as it does not remember passwords or anything. When closing this window, all record of the guest user having used Epiphany are forgotten.
Also shown in the figure is that the “private” instance of Epiphany has no favorite bookmarks, so GMail, Twitter, Facebook, Hi5 or any other service will require your login passwords each time. After closing the window, it will forget all the information you used.
I feel involved with you
You can contact developers by sending a mail (firstname.lastname@example.org) to the Epiphany mailing list. And the developers are also available to chat on IRC (irc://irc.gnome.org:6667/epiphany):
About the Author
Diana Katherine Horqque is – almost – a graduate of Industrial Engineering at PUCP (Lima – Peru), and is currently investigating her thesis on Sustainable Ecotourism in a Rural Education Environment (Project “Fe y Alegría”), as a result of her volunteer experience in the Peruvian Amazon. Nowadays she is highly motivated to deepen and learn more about the phenomenology of perception from Merleau-Ponty.
Ara Pulido reviews FOSS desktop application testing using a new API suite called Mago. Read on for an introduction to get you started in applying it to your open source desktop application.
Testing the GNOME Desktop
Growing complexity of software and, therefore, the amount of tests required before launching an application makes it necessary to automate some of those tests. Unit tests are more and more common in FOSS code but, sometimes, it is also useful to automate tests that interrogate the human interface.
Desktop testing automation refers to those tests that automatically test the GUI of an application, mimicking the mouse and keyboard movements that a human user normally performs. If you look for software testing automation in your favorite search engine, you will find a lot of search results about testing automation of web applications, lots of proprietary software to test proprietary desktop software, lots of FOSS to test web applications and some blogs about testing proprietary desktop software. What about testing desktop FOSS? What are the available solutions?
GNOME Accessibility & Desktop Testing Automation
In GNOME there are several frameworks, but they are all based in the accessibility information. The ATK layer in GNOME was originally written to be able to use GNOME with assisting technologies such as screen readers or Braille terminals. ATK describes a set of interfaces that applications need to implement in order to be accessible. It turns out, however, that the information exposed by this layer is really useful for automated desktop testing. Using this information, GNOME desktop testing frameworks can know, at anytime, which applications are running and which tasks can be performed.
Accerciser is one of the AT browsers to check accessible applications.
Any of these frameworks get the accessibility information from the AT-SPI layer, a communication layer based on CORBA. This communication layer is now being ported to D-Bus to make it work in the new GNOME 3.0.
Mago, A Desktop Testing Initiative
When I started with GNOME desktop testing automation there were some things I missed in the landscape of testing automation:
- A common repository: It is better to have a common repository of tests that everybody can benefit from.
- A defined process and better maintenance: One of the key issues of desktop testing automation is that tests are written, but then they are not maintained. A defined process will make maintenance easier for the original writer, or for someone else.
- Consistent run and reporting: Different tests written by different people should be run the same way and should get the same report layout.
Dogtail, Strongwind and LDTP are the three main available frameworks for desktop testing automation in GNOME. These frameworks expose a very complete API to control the applications: buttons, labels, menu, etc. Dogtail and Strongwind are both written in Python using the pyatspi library. LDTP, on the contrary, has its core written in C using the cspi layer which is now deprecated. LDTP2, however, is completely rewritten in Python, is an ongoing project, and a stable release is expected later this year.
So, is Mago one of these frameworks? The answer is no, Mago is not one of these frameworks. In fact, I like to call Mago an initiative, rather than a framework. Mago tries to solve the above issues by sitting on top of one of these frameworks, specifically LDTP.
The main reason why Mago is based on LDTP and not other frameworks is that LDTP is better maintained than the other two frameworks. The main problem of LDTP is that it is based on a library that is now deprecated. Fortunately, the LDTP2 API will be compatible with its predecessor.
How does Mago try to solve these problems?
The first thing that you will see when branching Mago is a folder structure to store tests. Those folders are named by application and you can easily browse the available tests for each of them.
Also, Mago recommends a way to write tests. Although Mago runs Python code and accepts any LDTP command, the recommendation is that each application needs an application wrapper and that each test suite needs to be a subclass of TestSuite, implementing the setup, teardown and cleanup methods:
- setup() is called once when the test suite starts running. It includes the operations needed in the application to leave it in a state where the test cases work.
- cleanup() is called between test cases in the same test suite. It includes the operations needed to leave the application in the same state as when the test suite started.
- teardown() is called once when the test suite ends. In includes the operations to leave the system in the same state as before it ran the suite (killing processes, closing applications, etc).
In most of the cases, you need to create test suites for a single application with little or no interaction with other applications. For those cases, in the setup method you might desire to open the application, while in the teardown method you might desire to close it. Mago already includes a TestSuite child called SingleApplicationTestSuite for these cases.
An instance of SingleApplicationTestSuite is always associated with an application
Lastly, Mago includes its own test harness and reporting system, that allows tests to be run consistently and get reports in both XML and HTML.
Let’s see how Mago can help you write your desktop tests using a simple example for gedit.
As you may guess, in the gedit folder, there are gedit test cases. Each test suite is defined in a XML file. In this file, you will define three things: the python class that contains the TestSuite child class, test cases and their corresponding python methods along with some arguments to pass to the test case methods.
<?xml version="1.0"?> <suite name="gedit chains"> <class>gedit_chains.gEditChain</class> <description> Tests which verify gedit's save file functionality. </description> <case name="Unicode Tests"> <method>testChain</method> <description>Test Unicode text saving.</description> <args> <oracle>data/utf8.txt</oracle> <chain>This is a japanese string: 広告掲載 - ビジネス</chain> </args> </case> <case name="ASCII Test"> <method>testChain</method> <description>Test ASCII text saving.</description> <args> <oracle>data/ascii.txt</oracle> <chain>This is a very basic string!</chain> </args> </case> </suite>
The actual code is where the magic happens. As we already have the gedit application in the Mago API and as we already have separated the data from code (with the XML/Python combination), the script is kept simple and easy to reuse and maintain:
import os from time import time, gmtime, strftime
from mago.test_suite.gnome import GEditTestSuite from mago.check import FileComparison, FAIL
def testChain(self, oracle=None, chain=None): test_file = strftime( "/tmp/" + "%Y%m%d_%H%M%S" + ".txt", gmtime((time()))) self.application.write_text(chain) self.application.save(test_file) # oracle file path is assumed to be relative # to test case code oracle = os.path.join(os.path.dirname(<i>file</i>), oracle) testcheck = FileComparison(oracle, test_file) if testcheck.perform_test() == FAIL: raise AssertionError, "Files differ"
If you run that test suite with mago, you will see this sequence:
- gedit is opened (setup)
- The first test case is run
- gedit closes the document and starts a new one (cleanup)
- gedit is opened (setup)
- The second test case is run
- gdit is closed (teardown)
The opening, clean up and closing of the application is done for you on the TestSuite level and you will only need to care about what you want to test in your test case.
What if you want to test an application that it is not yet in the Mago API? How do I tweak Mago to be used in my build system? How do I turn accessibility on? How do I run tests using Mago? There is a lot of information about Mago that I couldn’t cover in this article. The Mago website includes documentation and examples and the GNOME desktop testing mailing list is read by many Mago developers, contributors and users. These are great resources to further learn to utilize Mago for your custom application testing.
About the Author
Ara Pulido is a Spanish software tester working for Canonical as part of the Ubuntu QA Team. She believes that testing is a very much needed activity in FOSS and she will try to convince you of it.
When not at work you will find her cooking, traveling or lying on the beach.
Marina Zhurakhinskaya introduces GNOME Shell and its design goals.
GNOME Shell is the new face of GNOME. The goal of the project is to create a better design for the look and feel of the desktop and the key functions the desktop provides. These functions include enabling the user to find and open applications and documents, switch between various activities, and view incoming information such as chat messages or stock price updates. Many of these capabilities are already provided by the separate modules of the current GNOME desktop, but GNOME Shell integrates them in an overall comprehensive design.
I have been working on GNOME Shell since its conception at the GNOME UI Hackfest, which was held the week before Boston Summit in October 2008. My work includes writing code, weighing in on the design plans, and making sure that our wiki is up-to-date with all the information necessary to try out GNOME Shell or get started contributing to the project. I am part of the team of software developers and designers at Red Hat guiding the project. We actively work with the developers of the technologies GNOME Shell is based on (such as Clutter, Mutter, and GObject Introspection) and with many community members who contribute to the project. There are preview packages of GNOME Shell in many Linux distributions already and it is slated to be the default look of GNOME 3.0, which will be released in September 2010.
Our motivation in designing GNOME Shell is to provide a consistent, self-teaching user interface based around the day-to-day tasks of the user. Over time, the user should be able to grow in their use of the desktop, easily discovering the more advanced features and ways to personalize the desktop to reflect their work patterns and individual taste. In addition to taking responsibility for the user’s overall experience, we want to delight the user with sleek graphics and visual effects enabled by new graphical technologies. We also want to make it easy for the user to focus on their current task by de-emphasizing the other tasks and using the notifications sparingly in accordance with the user’s preferences.
The first noticeable change in GNOME Shell is that the two panels of GNOME 2 are replaced by a single black panel at the top of the screen. This panel contains some familiar things like a clock and notification icons, but the menus containing applications and other options have been replaced by a single button at the upper left of the screen that takes the user to the Activities overview. Next to the Activities button, is the name of the currently used application that will eventually contain the application menu, with options such as close, open a new window, as well as application specific options. Removing the second panel and some controls on the top panel creates more space on the screen for the application windows and removes from view the options that are only used momentarily and are not related to the current application. One way the user can switch applications is the improved Alt+Tab dialog that displays all open applications.
The most important of the innovations seen in GNOME Shell is the Activities overview mode which dedicates a full screen to all the different ways in which the user can switch from doing one thing (an activity) to doing something else. It shows previews of all the windows the user has open, the user’s favorite and running applications, favorite directories and connected devices collectively called “places”, and recent documents. It also integrates search and browse functionality in case what the user wants isn’t immediately visible.
The user can get to the Activities overview by clicking the Activities button or by simply moving the mouse to the upper left corner of the screen which activates the “hot corner”. The hot corner is a fast and easy way to get to the frequently accessed overview.
Like in GNOME 2, windows can be grouped into “workspaces”, but the GNOME Shell Activities overview makes workspaces much more intuitive. The user can easily see what is on all the workspaces, drag new applications or documents to a particular workspace to open them there, and drag windows between workspaces. The default is having one workspace and the user can add or remove workspaces as needed. In addition to making workspaces more intuitive, the view of what is on all workspaces allows the user to pick a window to switch to in a single step regardless of whether it is located on the same or different workspace as the user’s previous activity. Similarly, single step switching is available in the Alt+Tab dialog which shows applications open on all workspaces.
GNOME Shell puts a bigger emphasis on applications (Firefox, Evolution, Terminal, etc.) rather than on the separate windows of the application. The application icons in the Activities overview serve as both the application launchers and the indicators of which applications are running that let the user switch to the application. This replaces the custom launchers and the task list that was shown in the bottom panel in GNOME 2. The running applications are indicated with a glow behind the application name and the glow is broken up into multiple circles if the application has multiple windows open. Clicking on the application icon opens a new window for the application if it was not running or switches to the last used window of that application if it was already running.
Consider the case of a web browser with tabs, the title and the appearance of the window will differ depending on what tab is open. By emphasizing the Firefox name and icon, we’ve provided a consistent target for switching to the application. Furthermore, right clicking on the application icon brings forward the previews of all windows of the application, which takes the guess work out when compared to clicking on the poorly identifiable targets in the GNOME 2 bottom panel before stumbling on the window you meant to restore. An option to open a new window is available from the right click menu along with the titles of the current windows. Similarly, the Alt+Tab dialog groups open windows by application and provides large previews of the windows when the application icon is selected.
For many applications, such as XChat IRC, Empathy, Evolution, Calculator, or Chess, it makes most sense to only run one instance of the application, so switching to the existing window of the application is what the user wants if the application is already running. However, in GNOME 2, the user had to know whether such application is already running before making a decision to click on a launcher to open a new window of the application. Accidentally opening a duplicate window could mean having an unnecessary extra Calculator window cluttering the desktop or signing in into IRC under a second nick. By combining the application launcher and the application switcher and making switching to the already running copy of the application the default behavior, we give the user confidence that if they just go ahead and click on the application icon, the right thing will happen.
Trying out GNOME Shell is easy. It is stable and convenient to use in its current state and many people already use it as their default desktop. Many Linux distributions have the GNOME Shell preview packages available.
On Fedora 12, you need to run ‘sudo yum install gnome-shell’ and then select GNOME Shell in the System->Preferences->Desktop Effects dialog.
On Ubuntu 9.10, you need to run ‘sudo apt-get install gnome-shell’ and then run ‘gnome-shell—replace’. You can run ‘gconftool-2—set /desktop/gnome/session/required_components/windowmanager—type string gnome-shell’ to always start GNOME Shell when you log in. You can run ‘gconftool-2—unset /desktop/gnome/session/required_components/windowmanager’ to reverse this change.
Instead of using a package, you can also build, run, and periodically update GNOME Shell yourself using these straightforward jhbuild instructions, which will allow you to stay on top of the GNOME Shell development changes. Be sure to check out the GNOME Shell cheat sheet when you start using GNOME Shell.
The current work items for GNOME Shell include adding a new message tray and notification system, improving application and document browsing, and creating an extensions system which will allow developers to create custom plug-ins for GNOME Shell. We welcome design input and development help for these and other GNOME Shell features. You can get involved by joining the GNOME Shell mailing list, hanging out on the IRC channel “gnome-shell” on irc.gnome.org, reading the design document, going over the information on the development page, adding a translation for your language, and filing or fixing bugs in Bugzilla. The best place to discuss what you want to contribute or ask for help is the IRC channel. Lurking there is also fully acceptable!
About the Author
Marina Zhurakhinskaya is a Senior Software Engineer working on the new shiny GNOME Shell code on the desktop team at Red Hat. She is particularly interested in making sure that the GNOME desktop is intuitive for the users and well-documented for the contributors. Outside of work, she likes to hang out with friends and family, travel, listen to audio books, and read reviews on Yelp, TripAdvisor, and Amazon.