Category Archives: July 2009

Behind the Scenes with Owen Taylor

Paul Cutler interviews Owen Taylor, maintainer of GNOME Shell and Sysadmin team member. Owen talks about how he became involved with GNOME, GNOME’s recent Git migration, and the GNOME Shell project.

 

Short Intro

  • Age: 35
  • Located in: Waltham, Massachusetts, USA. (near Boston)
  • Profession: Software Developer
  • Nickname on IRC: owen
  • Homepage and blog: http://fishsoup.net

Interview

In what ways do you contribute to GNOME?

I’m currently leading the GNOME Shell project. I act as a Red Hat contact point for the GNOME servers hosted at Red Hat, and also pick up various sysadmin projects when time allows, like the recent migration from SVN to Git. In the past, I’ve been a GNOME board member and chairman, as well as the maintainer of GTK+ and Pango.

How and when did you get involved in GNOME?

I was doing work on GTK+ and the GIMP before I started at Red Hat in 1998. I tried compiling an early version of GNOME, but it really didn’t do much: It was pretty much just a gray bar at the bottom of the screen with a clock on it. So, I went back to working on GTK+. After I started at Red Hat, I became more involved with GNOME; we had a big push to get GNOME 1.0 out the door, and to make it something we could ship with Red Hat Linux 6.0.

What motivates/keeps you motivated to work on GNOME?

After 11 years, the inertia is pretty strong… More seriously, GNOME provides a great opportunity for having a big impact. You make a change within GNOME, and it’s going to end up on millions of desktops. With that multiplier, even the smallest change adds up to a significant improvement to the world’s computing experience. (Assuming that the change is for the better; we only make changes for the better, right?)

You are currently working on GNOME Shell. How would you describe what GNOME Shell is? How is it different for a user from today’s GNOME experience?

GNOME Shell is a replacement for the parts of GNOME that go “around” the applications; it takes over the application launching, window management, and task switching roles currently provided by Metacity. Part of GNOME Shell is simply a refresh of the visual experience; taking advantage of the capabilities of today’s graphics processors to provide an attractive, clean, and smoothly animated user experience. But GNOME Shell goes beyond that to rethink some of the fundamental usage patterns; how can we provide a workflow that assists the user in efficiently moving between different tasks, rather than making them do busy-work to manage their files and applications? How should the desktop be different if the user is spending most of their time in the web browser and chat program, rather than in word processor documents and spreadsheets?

GNOME Shell is being developed in JavaScript. What advantages does developing in JavaScript bring?

One obvious advantage of JavaScript is that a lot of people are familiar with it from the web. But maybe even important for us was the fact that JavaScript has a very limited built-in library. That might sound like a disadvantage rather than an advantage, but GNOME already has a rich platform: the GNOME libraries, which are available to JavaScript code via gobject-introspection. Avoiding duplication reduces overhead and developer confusion.

What is the release plan for GNOME Shell?

GNOME Shell won’t officially be part of GNOME 2.28 but we’re going to have a preview release that is coordinated with the GNOME 2.28 release. Our goal for that is have a something that works well for day-to-day use so we can try it out with a broad spectrum of users trying it out and have real-world data about what works and what doesn’t prior to GNOME 3.0.

How can developers get involved with GNOME Shell?

GNOME Shell is really easy to build and try out: we have a self-contained “jhbuild” that allows building gnome-shell and all the modules it depends on with just a few commands. Build instructions are at http://live.gnome.org/GnomeShell. At the same place, there is background about the design of the shell, and suggestions for easy introductory projects. You don’t have to be a coder to join the project. If you are a graphic artist, if you have a talent for working through the details of a user-interface design, if you’d like to help with end-user testing, there’s a need for that as well. If you want to chat or hang out and see what’s going on, you can find us on the #gnome-shell channel of irc.gnome.org.

You recently helped with GNOME’s migration from SVN to Git. What went well? What was the most challenging part?

What went well is that we’re migrated over now, it seems to be working smoothly, and I think people are settling in and learning the ins and outs of Git. I definitely find it makes a big difference to the efficiency of my day-to-day work as compared to SVN.

The really challenging part was dealing with all the obscure things that had been done to GNOME svn repositories. Because SVN is very free form, you can do do all sorts of things to a SVN repository that aren’t really tags, or branches, or anything else that you can represent in easily Git. So, Kristian Høgsberg had to go through and figure out individually some sort of handling for these cases and make our conversion tools do that.

Personal

Favorite food?

My personal domain ‘fishsoup.net’ gives a clue to one of my favorite foods. Give me a bowl of hot spicy broth teaming with different types of seafood, and I’m pretty much in heaven.

Favorite band or song?

How about a favorite fiddle tune composer? One of the things I do in my spare time is play traditional Irish music on the fiddle, and of the tunes that I come back to again and again, a disproportionate share seem to be by Ed Reavy, who was born in County Cavan, but spent most of his life in Philadelphia.

Favorite vacation spot or place to visit?

About 10 miles south of where I live, there’s a park (or “reservation” in local terminology) called the Blue Hills, which is a pretty nice place to go off and hike for a couple of hours. There are some excellent views over the city and Boston harbor, but once you get away from a few popular spots, you can also have the trails pretty much to yourself.

Discuss this story with other readers on the GNOME forums.

Do-licious

Jorge Castro takes a deeper look at GNOME Do and explores some of its more advanced features.

Introduction

GNOME Do is a popular application that started off as inspired by gnome-launchbox and the “open version” of Quicksilver. However, over the last year the project has branched out in its own innovative ways, providing a tool for people to build innovative plugins and features. In this GNOME Journal article we will go beyond the normal launcher features and get into more advanced usage of GNOME Do and take a tour of some of the newer features available.

The Basics

At it’s heart GNOME Do is a launcher. It’s not designed to be in your face all the time; you merely summon Do when you need it and then it does what you want and gets out of your way. By default GNOME Do binds itself to Super-space, which on most keyboards is the Windows key + the spacebar. After you summon GNOME Do the UI pops up with 2 boxes. The first box accepts input from you, these are known as commands. The second box are arguments which are passed onto the command in the first box. You merely type out your command, hit tab to go to the next box, type your argument, and hit enter? Sound complicated? Don’t worry, it gets easy with examples.

Let’s say you want to launch Epiphany, the GNOME web browser. Summon GNOME Do by hitting Super-space, then start typing in “web browser”. GNOME Do will auto-complete your phrase, then just hit enter. The web browser will then launch! If you repeat this command, GNOME Do learns what you did last time, and it learns much quicker. As you use Do, the common shortcuts are quickly learned, and GNOME Do “grows into” your workflow. The second box merely lets’ you add an argument to the command. When combined with plugins, this can become a very powerful combination:

In this more advanced example I have typed out “Grace Under Pressure”, one of my favorite Rush albums. When I hit tab I have the option to ask Rhythmbox to play the album, or if I hit the down arrow key add it to my play queue. In this way I can use plugins and the two panes of GNOME Do to come up with different combinations to get things done. For more information about basic GNOME Do usage, see this Linux Journal article.

Rocking Out With Your Dock Out

“Docks” have never been scarce on the Linux desktop; this user interface feature, made popular by Mac OS X, has had many popular incarnations, such as the Avant Window Manager and the Cairo Dock. Last summer, the GNOME Do developer team decided to try to make something even sexier. And thus began Docky, the Dock for GNOME Do. Unlike the other docks, Docky would build upon GNOME Do and be an optional plugin, so that the dock could use some of GNOME Do’s built-in learning and searching features while providing a launcher that sat on your screen as opposed to being invoked like GNOME Do.

Docky would have some very different features from other docks. First of all, the default applications shown would be determined by how popular they were. If you happen to launch Firefox 50 times a day, it would just show up in Docky. So, the more you used an application, the greater chance it had in showing up in Docky when you fired it up. This was a good approximation of what the user would generally want. Of course, you have the option of making an application “sticky” by right clicking on it and choosing to always have it on the dock. On top of being a launcher, once you launched an app it shows up with a little glowing dot below the icon. As you can see in the screenshot, I am running all the applications on the dock except for the Epiphany web browser.

In this way, Docky is not only a launcher, but it is a task manager, showing you which applications you are currently running. Applications can be drag and dropped to any position on the dock, and the far left icon is used to set docky preferences and determine behavior. Hovering the mouse over the right or left edge of docky lets you resize it horizontally. This allows you to determine exactly how many applications you want in Docky based on how much room you give it. The larger you make Docky, the more applications fit on it. Docky does it’s best to put the applications you use the most in the space given. As you use docky it learns which applications you launch the most and puts them in the UI; so the more you use Docky the more it learns about which applications you use the most. The horizontal spacer is used to resize the dock vertically, which will cause the icons to resize themselves automatically to fit the amount of room you give it:

Docky relies heavily on the compositing features of the Linux desktop, your video card and drivers need to support compositing or the Docky option in GNOME Do will not be selectable.

Plugins

Plugins are the bread and butter of GNOME Do, without them Do is just a fancy launcher. I am going to go over some of my favorite plugins to show how I use them to make my life easier. To install a plugin merely click on the down arrow in the Do interface and select Preferences. From there you can install plugins.

Paste2

As open source developers and users we spend a great deal of time collaborating over mediums like instant messaging, internet relay chat, or other real-time means. Working on UNIX-like systems leads to a very text-oriented workflow. Usually when we need help with something we need to show the person helping us a bunch of text output. Since pasting lines and lines of UNIX drivel into an IRC channel isn’t very polite someone invented something called a pastebin, which is a place where you can paste a bunch of text and then have a single URL you can paste to someone. The paste2 plugin for GNOME Do let’s you highlight a bunch of text and automatically send it to paste2.org, one of the many pastebin services on the web. The first step is to highlight the text you want to pastebin, then summon gnome-do and start typing in “pastebin” until Do selects the “Send to Pastebin” command. Then hit enter. GNOME Do will then take the text you’ve highlighted and send it to paste2.org. Then the magic happens. Do will then take the URL that your post will be sent to and then populate the URL in GNOME Do’s UI. Hit enter and it will automatically open your web browser with the paste2.org URL. If you don’t want to go there you don’t have to, Do has also automatically put the URL in your clipboard, so you can just go ahead and paste it into your IRC or instant messaging client.

Microblogging

Microblogging services such as Twitter and identi.ca have become a popular medium for people to communicate their ideas. After you install the plugin you need to configure your account details. After that you merely summon Do, type what you want to post and then hit tab and select “Post to identi.ca” or twitter. Since microblogging is limited to 140 characters the small Do window becomes a perfect place to fire off your status updates. The plugin will also take the status updates of your friends and pipe it through your notification system for you.

man

The man plugin is straightforward – Summon Do, type “man”, hit tab, and then the command you want the man page for. I find this much quicker than summoning a terminal and using the man command. The information is presented in GNOME’s Yelp utility, which provides bookmarking, searching, and formatted text. My workflow usually involves summoning the man page and immediately printing. I can do this with a few keystrokes.

Working with Tomboy

Tomboy is a great note taking tool that ships with the GNOME Desktop. Usually when I am typing an email or writing something I will realize that I will want to put it in a note and then refer to it later. The Tomboy plugin provides several shortcuts to make using Tomboy easier to use while typing. Firing off a new note is easy, I summon Do and start to type “New Tomboy Note”. Remember that Do learns as you type; since I use this functionality often I summon do and it only takes hitting “N” for Do to find that that is the command I want and then I hit enter and a new note is created.

The plugin also works like the paste plugin. Do treats selected text as something that you can run commands against. So selecting text in your documents and then summoning the Tomboy plugin will automatically put the text into a Tomboy note. This is handy because copy and paste has been an area that could be improved within Linux, and Do makes it easy.

Messaging Friends

There also GNOME Do plugins for messaging and calling friends. Currently there are plugins for Skype, Pidgin, and Emesene. Instead of browsing a large list of possible contacts I use my natural thought process. When I want to talk to Ryan I just summon Do, start typing his name, and then hit tab and select if I want to instant message him over Pidgin or chat via Skype. Since Do talks to my instant messenger program it puts that person’s avatar in the user interface, so when I am typing quickly I can use that as a confirmation that I am writing the correct Ryan, in case I have multiple ones in my contact list.

Conclusion

As you’ve hopefully come to realize from these examples there are certain best practices that you can use in GNOME Do that will always work.

  • GNOME Do learns. As you type out commands Do gets a bit smarter every time. At first you might have to type out “Web Browser”, the next time typing “Web” will autocomplete the command, and by the time it’s learned your commands you can summon the most common ones with one letter.
  • Highlighting text can be used as input. When you select text think about how that can be fed into the plugin you want to use. You’d be surprised what works when you follow conventions from other commands.
  • It’s more than a launcher.
  • Derive for fun. Many Do plugins are just modifications of other plugins but made to work with other programs and other web services. You are encouraged to make your own plugins for whatever you want and submit them to the project.

About the Author

Jorge is a member of the GNOME marketing team, an Ubuntu enthusiast and works on the Community Team on External Developer Relations for Canonical Ltd.

Discuss this story with other readers on the GNOME forums.

Time Tracking with Project Hamster

In this article, Les Harris takes a look at Project Hamster, a recent addition to the GNOME Desktop that helps you track your activities over time.

Time Tracking with Project Hamster

According to their entry on GNOME Live, Project Hamster is “time tracking for [the] masses.” It aims to be a tool which enables users to quickly and accurately keep track of the amount of time they spend on their activities over time. Project Hamster is a relatively new module for GNOME, having been brought into GNOME officially for the 2.24 release. Now that GNOME 2.26 is upon us, it is an ideal time to take a closer look at this interesting project. This review will be covering hamster-applet 2.26.0.

Taking the Hamster Wheel for a Spin

Hamster is a panel applet, so it must be added to a panel in order to use it. Its interface is very streamlined. In the panel, it displays both the current activity that is being tracked, as well as the amount of time spent on the activity. The displayed information acts as a button; when clicked it stays depressed and Hamster’s user interface pops up.

The current activity can be selected in the text entry at the top. The entry includes a drop-down list of all defined activities along with their categories. If the user wants to start an activity that isn’t already defined, he simply enters a name for the new activity in this area. Hamster provides an overview of all the activities tracked for the current day. This allows the user to see what they have been doing at a glance. It’s possible to edit the start and end times for each activity in this list using a small edit icon that appears in each row. Under the overview list is a breakdown of the time spent on each category of tasks for that day, which could be a useful feature. Rounding out the main user interface are two buttons: the first lets one add an activity for any arbitrary date and time, and the second brings up the activity overview window, which is discussed later.

Hamster tucks away its minimal preferences in a contextual menu from its panel button. If users are familiar with searching for additional program options in such menus, then they will eventually find it. However, its discoverability is low, as there is no other way to access it.

The first batch of preferences involves creating categories and defining activities within those categories. Creating a category or activity will make a new item in the list appear which automatically prompts for the name. Renaming an entry involves clicking on it, and the text becomes editable—which is an enjoyable little touch. An idiosyncratic quirk of naming is that the text is automatically modified so that only the first letter is capitalized. In this version, there is no way in the user interface to disable this behavior. Activities can be moved to different categories with a drag-and-drop action. It isn’t immediately clear how to remove an activity or category after it is created, but after some exploration, I determined that a simple press of the Delete key will do the trick. I also could not find a way to create a category, or to assign activities to a category outside this window. This likely isn’t an issue for categories since their creation will occur less frequently, but it would be nice if there was an easy way to assign categories to activities from elsewhere.

There are only a few additional preferences for Hamster. You can control when Hamster should automatically stop tracking time. A possible use-case for not enabling this feature would be if the user routinely includes tasks that take the user away from the computer, and the user would like the tracking to continue while away. Also, the slider controls how often Hamster will display its unobtrusive notification, which serves as a visual way of informing the user they are still working on a particular task. Lastly, the global hotkey preference controls which key combination the user can use to activate the Hamster application without using the mouse.

The real power of Hamster comes into play with its aggregate display of tracked activities. The visual breakdown of time worked per day is useful, but having easily understood visualizations for total amount of time spent on a category and activity basis really helps to intuitively understand where the user’s time is spent.

The interface for the overview window is admirably simple. Tasks can be added, removed, and edited by selecting them and clicking the appropriate button. The next and previous arrows are smartly implemented. While in month mode they will move to the next or previous month respectively, and they continue to do the right thing in week and day modes as well. The home button is also implemented in this context-aware fashion and will return the user to the current day, week, or month depending on the view being shown. All in all, it is a good example of the principle of least surprise.

The final button in the overview window generates a nicely formatted HTML report of all your activities for the current day, week, or month that is easily sent out or archived.

Hamster Dancing

As a whole, Project Hamster is a perfect example of the old UNIX philosophy of doing one thing and doing it well. The program is full of helpful little touches. This is the kind of polish that only love can bring to a project. The Project Hamster team should feel rightly proud of the work they have done.

In particular, I enjoy the global hotkey which enables me to stay on the keyboard and make quick activity updates without breaking my flow by moving to the mouse. The text entry in the main user interface includes a drop-down list that suggests activities based on what you type. The highly polished overview window is a joy to use, and the graphs it generates are both functional and good looking. I am also taken with the way Hamster displays the total time tracked per category in the main user interface on an on-going basis.

After using it, there are a few areas where I would love to see some additional attention. It would be nice if the user interface was a bit more discoverable. Many features are hidden in the interface, and only reading documentation will bring them to surface. Depending on how old-school you are, this may or may not be seen as a problem. In addition, Hamster only deals with a 24-hour clock rather than the AM/PM 12-hour clock. It would be nice if there was a user-settable way of choosing which mode in which to work.

The report generator function could be made more useful if there was a way to filter the results by category, activity, and time span. A possible use-case for this feature would be a contractor who only wants to send her client the logged hours for their particular project.

Integration work with programs like Evolution and Tasque would be an absolutely killer feature. A Hamster that can pull activities from Evolution’s calendar, and tasks from Tasque, would be an extremely powerful time tracking tool.

Final Thoughts

There is nothing really like Hamster out there right now. It fills a unique niche that many working professionals need filled, but in a friendly enough manner to enable anyone to track the amount of time they spend on things. It’s a great little program with a highly active development team. Interested parties are encouraged to check out the Project Hamster blog where Tom routinely writes about features and design work being done in Hamster.

Overall, it’s a great program, and if you can see a use for time tracking, you owe it to yourself to check it out. To learn more about Project Hamster, visit their wiki homepage or blog. Hamster is available for all major GNU/Linux distributions typically with the package name hamster-applet.

About the Author

Les Harris is a long time contributor to the GNOME Mud project, and was recently married.

Discuss this story with other readers on the GNOME forums.

Working With Upstream: An Interview with Laszlo Peter

Laszlo (Laca) Peter is a release engineer at Sun Microsystems working on Sun’s Desktop team. Stormy Peters interviewed Laszlo to learn more about how companies working with desktop technologies can work effectively with the upstream GNOME teams.

The Interview

Laszlo, many companies have trouble working upstream. I understand that Sun made a big push a few years ago to work more effectively upstream and it’s been very successful. Can you describe the problem that Sun was having before you started your upstream push?

When we started to work on porting GNOME to Solaris, it always took us a good while to get to the point where we could build it and use it.

We needed lots of code changes. By the time we finished, a newer version of GNOME was out. The new version would be equally broken on Solaris and most of our code changes didn’t apply to the new version, so the whole process started again and we never seemed to catch up.

We realized that we needed to work with the GNOME developers to integrate our patches in the upstream code so we wouldn’t need to do this for each and every release.

Working upstream was good in theory, but in practice, our patches were all 6 months behind. Sending patches that were against 6-month-old code didn’t help much because the code had moved on and the maintainers were not interested in forward-porting our patches. So we realised we have to work with the latest and greatest community code and send patches as soon as we notice that the code breaks on Solaris.

What does it mean to push something upstream?

First of all, [it means] writing patches that are acceptable in the community code base (i.e. a fix for Solaris doesn’t break the code on other OSs) and then sending it to the maintainer/list/[bug tracker] as soon as possible, so they can easily incorporate it in the community code base.

What did you have to change internally? What did you have to do differently in order to work upstream?

We had to adopt our internal processes to make sure we didn’t start lagging behind the community code base again. We need to keep working with the latest code, reporting issues upstream as soon as we find them.

Catching up is much harder than keeping the pace. Just like upstream, we have two active branches of our desktop: the latest stable version goes into Solaris and goes to our customers, and we only fix the really nasty bugs in this branch. The development branch is what we concentrate our efforts on. We keep updating the development branch with the latest GNOME development tarballs as soon as they are released and each tarball has an internal owner who is responsible for updating internal patches when they break. If they do their jobs well and get their patches upstream, they have less work to do. That’s quite an incentive. 🙂

Another incentive for Sun developers to write good patches is that we require internal review of all patches that are not pushed upstream… if a patch is pushed upstream, we trust the maintainer’s opinion so it need not be reviewed internally.

Does that mean you have more people working on GNOME now? Do you have to have an internal developer for every external GNOME maintainer?

No. Like in the community, one person can maintain more than one package. Since our internal maintainers are only responsible for maintaining (or rather: reducing) the difference between the upstream code and Sun’s code, they are able to maintain many packages.

Was it a hard sell internally?

Not really. It makes a lot of sense to work this way.

Did pushing things upstream slow you down?

On the contrary. It made us more efficient than ever before. We manage more packages, keep them better updated and they work much better on our platform, out of the box.

Do all of your changes make it upstream? What happens when they don’t?

No, not all changes are accepted. There are different situations. The worst one is if a patch we submit is ignored. In that case, we don’t know if it’s acceptable or needs work. In some cases, the upstream maintainer has different ideas about a fix. We want our engineers to negotiate and rewrite their patches if needed, until they are accepted. Finally, in some cases the maintainer disagrees with the bug report itself and is not willing to accept the changes in any form. In this case, we need to re-evaluate the bug internally.

If we decide that we still want it, because our customers want it, we will keep the patch. These are patches that we really hate because they need to be merged with the upstream code changes all the time.

What types of things do you push upstream? Are these Sun specific features? Things just your customers have run into? Things you think would be cool?

Preferably everything. In the case of features, it’s a good idea to work with the upstream developers from day one and maybe develop in a branch of the upstream SCM [(source code management)].

Are you still able to get customers the products they need, when they need them and still work effectively upstream?

Yes. We can make the changes that the customers require in the stable desktop and not necessarily push that specific change upstream. At the same time, we come up with a long term solution for the problem and implement it in the latest development code.

Do you push out changes to customers and then push them upstream? Or do you push them upstream and make sure they are accepted before you use them in customer products?

We concentrate on the development version of the desktop and push most fixes upstream before the stable release. Patches that do not get accepted before the stable release will make it in the customer product first.

When someone in the company is new to open source, how do you educate them on how best to work with the upstream community?

Working with the community is part of the process, if you like, part of our job description. In my experience, most people get it quickly. Others may need a little push.

What advice would you give a company trying to work upstream?

Encourage your developers to communicate and work closely with the community. Send them to developer conferences and summits to meet them face to face. It’s much easier to work with someone when you can put a face to a name, and code changes are more easily accepted after a beer or three. 🙂

What could the community do better to help companies like Sun work effectively with upstream?

Review our patches in a timely manner. The worst feedback is no feedback.

For companies looking to work more closely upstream, can you give them an idea of how hard this was to implement? Did it take a lot of convincing? A lot of time up front? Are you saving a lot of time now?

When a company decides to use code from an open source project, they give up control over the changes and directions of the code base. They become part of the community and can influence decisions just like any other community member, but ultimately they lose control. Their best shot is to participate in the community and understand, discuss, influence design decisions.

However, the company still has full control of their internal processes. They can and have to define them such that they can provide what their customers want while they still go with the community and not against it. The initial implementation is likely to take significant effort, but they will save that later.

About the Author

Stormy Peters is the Executive Director of the GNOME Foundation. This is her first article for GNOME Journal.

Discuss this story with other readers on the GNOME forums.

An Introduction to GNOME Zeitgeist

In this article, Natan Yellin writes about GNOME Zeitgeist, a new user interface for documents and user information in the GNOME desktop currently planned for GNOME 3.0.

Introduction

Zeitgeist is a data engine for the GNOME desktop. It logs and tags every document, website, conversation, email, note and application that’s opened on the GNOME desktop. All of the information is stored in one central database for quick access and any application can easily add it’s own data to the mix. There are several user interfaces which show the information stored in the database, sorting it by type, date, or relevance to other files. They let users tag documents, bookmark them, and even attach custom notes to each item in the database. One of the interfaces, currently being developed by Siegried Gevatter as a Google Summer of Code project, even shows information from Zeitgeist inside the new GNOME Shell.

History

Zeitgeist was founded eight months ago after the GNOME User Experience hackfest in Boston. The first prototype was based on Mayanna/Gimmie and had only two regular developers who hacked on it in their free time. Today, we have a whole new codebase and there’s already six developers who commit code on a regular basis and several other community members who help test Zeitgeist, handle bugs, and design mockups for future user interfaces. The Zeitgeist team recently presented at the Ubuntu Developer Summit and Zeitgeist is slated for adoption in future versions of UNR (Ubuntu Netbook Remix). Zeitgeist is also going to be used in the as-of-yet unreleased Ubuntu Parental Controls and is even at the heart of a thesis paper and a PHD research paper at a German university.

Parts of Zeitgeist are based on ideas from the “Document Centric GNOME” presentation which Federico Mena-Quintero gave at GUADEC 2008. His ideas inspired a journal and a calendar interface for Zeitgeist which lets users view files that they edited at previous points in time. In accordance with some observations made by Dave Richards at the User Experience hackfest, some of the Zeitgeist interfaces hide filenames and directories from users in an attempt to free them from worrying about where files are located on the hard drive. Instead, users can tag the files and find them based on what type of file they are and what other files they’re related to.

GNOME Zeitgeist

The current user interfaces for Zeitgeist do not give users a hint of the real power which lies dormant under the surface. Our current goal is to index as much information from as many different sources as fast as we can. Once that’s done, it’ll be easy to build exciting new user interfaces which pull information out of Zeitgeist’s database and display it to users in all sorts of innovative ways. For example, it should be possible to let users build their own interfaces where they define what documents they want to see and how they want those documents to be organized. For example, one recent mockup lets users build custom “Smart Feeds” which aggregate together all sorts of different files according to user-defined filters.

One of the key concepts in Zeitgeist is that users care about “Documents” and not “Files.” In other words, users don’t want to be bothered with the distinction between documents that are on their computer (files) and documents that aren’t on their computer. Therefore, we have plans to index documents from online sources such as Google Documents, Flickr, and Launchpad. In a world where everything is online, there’s no reason why file managers should focus only on local files!

The biggest question that we’re currently trying to answer is what’s next. We’re already planning on adding on support for optionally using Tracker or CouchDB as a backend in place of our own database. The aforementioned “Smart Feeds” are also on the development map along with UbuntuOne integration, LAN powered “Shared Feeds,” and support for associating people with documents. However, we’re a versatile bunch and after that anything is possible.

Summary

Zeitgeist is about humans – especially people like you and me who like technology and want to make a better user experience for everyone. We care just as much about the team work and the international cross-cultural collaboration that drives our work as we do about the end product that we ship. We love to see new faces and hear new voices. A lot of our best mockups are scribbled in love on the back of cafe napkins, which just goes to show that you don’t need fancy paper or great artistic skills in order to innovate. We’d love to hear your voice as well. When we’re not sleeping, we live in the #gnome-zeitgeist channel on irc.gnome.org and will soon have our own website up at zeitgeist-project.org. We look forward to seeing you and hearing your idea for GNOME 3 and the next generation user interface. Welcome to Zeitgeist!

About the Author

Natan Yellin is a high school student in Ra’anana, Israel. He first became involved with GNOME development through Google’s Highly Open Participation contest in 2007. Since then, he helped start GNOME Zeitgeist and several other open source projects. When he’s not coding an open source project or doing freelance development, Natan can be found at his school’s robotics lab, with friends, or practicing one of several styles of Karate. He usually tries to blog about what he’s working on at http://theesylum.com/.

Discuss this story with other readers on the GNOME forums.

Git for GNOME Translators

Og Maciel provides an overview of using git to help translate GNOME, including setting up git, translating strings, and pushing changes to GNOME.

About the migration from subversion to git

Shortly after GNOME 2.26.1 was released, the GNOME project made the long waited migration from hosting most of their modules in Subversion to using Git as their main DVCS. The decision was taken after a long and painstaking process that included an online survey as well as many different threads and heated discussions taking place on mailing lists. It is not the objective of this article to discuss the merits of this decision and suffice to say that the task of migrating the many modules that comprises the entire GNOME cosmos was brilliantly handled by the migration team who were able to ensure that everyone had their modules available for use once the smoke settled.

Having spent most of my open source time dealing with Subversion to do translations for the Brazilian team, it was time then for me to let go of the past and embark on a new voyage of learning. It is the objective of this article to show how I’ve adapted my existing process of doing translations to use Git as well as share some tips that may be helpful to my fellow translators out there.

Getting started with git

The first thing we’re going to do is configure git so that it “knows” a little bit about you, so open up a console and run the following commands:

$ git config --global user.name "Og Maciel"
$ git config --global user.email ogmaciel@example.com
$ git config --global color.ui auto

These commands will garantee that all of your commits will contain your user credentials as well as provide colored output for most commands we issue. You can verify what your current settings are by looking at your $HOME/.gitconfig file or running:

$ git config -l
user.name=Og Maciel
user.email=ogmaciel@example.com
color.ui=auto

I also like to add a couple of alias to some common commands, specially the one that is recommended to run when you update an existing checkout:

$ git config --global alias.up "pull --rebase"

As explained by the official GNOME GitHowTo, “the—rebase parameter is very important. Suppose that while you were updating your translation, another person pushed their own work. In this case, your local repository will be missing those commits and your attempt to push your work will fail. The—rebase parameter in git pull—rebase updates your local repository and any commits you performed are adapted so that they appear as if they have been done at the moment you run this command.”

Here is what my current $HOME/.gitconfig file looks like:

[user]
name = Og Maciel
email = ogmaciel@example.com
[color]
ui = auto
[alias]
up = pull --rebase
ci = commit
stat = status
st = status
co = checkout
br = branch
df = diff

For the remaining of this article I will use the Deskbar Applet module to demonstrate how you would use both Damned Lies and Git to do some serious translation!

Checking out a module

For those who do not have commit access to the GNOME repositories, you can check out the source code for the deskbar-applet module running the command:

$ git clone git://git.gnome.org/deskbar-applet

If you do however have commit access, you can then check out using the following syntax:

$ git clone ssh://USERNAME@git.gnome.org/git/deskbar-applet

where USERNAME is your valid user name associated to your ssh key. Once you run one of these commands you should have a deskbar-applet directory created in your current directory. That’s not too complicated but are you sure you’re going to remember this syntax say, 2 weeks from today? I don’t know about you but I really like shortcuts and simpler things to remember, and a really nice tip for checking out GNOME modules is to run the following command:

$ git config --global url.ssh://ogmaciel@git.gnome.org/git/.insteadof gnome:

This will add the following section to your global git configuration in your $HOME/.gitconfig:

[url "ssh://ogmaciel@git.gnome.org/git/"]
insteadof = gnome:

Once you’ve added this little nugget you will then be able to checkout any GNOME module by running:

$ git clone gnome:deskbar-applet

Obviously, if you don’t have commit access you should change the url to use the generic git://git.gnome.org form.

We now can take a look at the contents of the deskbar-applet:

$ cd deskbar-applet/
$ ls -l
<del>rw-rw-r</del>- 1 omaciel omaciel 967 2009-06-07 20:01 acinclude.m4
<del>rw-rw-r</del>- 1 omaciel omaciel 161 2009-06-07 20:01 AUTHORS
-rwxrwxr-x 1 omaciel omaciel 1014 2009-06-07 20:01 autogen.sh*
<del>rw-rw-r</del>- 1 omaciel omaciel 266205 2009-06-07 20:01 ChangeLog.pre-git
<del>rw-rw-r</del>- 1 omaciel omaciel 6759 2009-06-07 20:01 configure.ac
<del>rw-rw-r</del>- 1 omaciel omaciel 17992 2009-06-07 20:01 COPYING
drwxrwxr-x 3 omaciel omaciel 4096 2009-06-07 20:01 data/
drwxrwxr-x 7 omaciel omaciel 4096 2009-06-07 20:01 deskbar/
<del>rw-rw-r</del>- 1 omaciel omaciel 1221 2009-06-07 20:01 deskbar-applet.doap
drwxrwxr-x 3 omaciel omaciel 4096 2009-06-07 20:01 doc/
drwxrwxr-x 16 omaciel omaciel 4096 2009-06-07 20:01 help/
<del>rw-rw-r</del>- 1 omaciel omaciel 9498 2009-06-07 20:01 INSTALL
drwxrwxr-x 2 omaciel omaciel 4096 2009-06-07 20:01 m4/
<del>rw-rw-r</del>- 1 omaciel omaciel 119 2009-06-07 20:01 MAINTAINERS
<del>rw-rw-r</del>- 1 omaciel omaciel 309 2009-06-07 20:01 Makefile.am
<del>rw-rw-r</del>- 1 omaciel omaciel 104649 2009-06-07 20:01 NEWS
drwxrwxr-x 2 omaciel omaciel 4096 2009-06-07 20:01 po/
<del>rw-rw-r</del>- 1 omaciel omaciel 1524 2009-06-07 20:01 README
<del>rw-rw-r</del>- 1 omaciel omaciel 2819 2009-06-07 20:01 TODO

We can also take a look at all the existing branches:

$ git branch -a

* master
origin/GSOC_2007
origin/HEAD
origin/button-ui
origin/cuemiac
origin/deskbar-0-8
origin/gnome-2-14
origin/gnome-2-16
origin/gnome-2-18
origin/gnome-2-20
origin/gnome-2-22
origin/gnome-2-24
origin/gnome-2-26
origin/index
origin/master
origin/old_handlers

Doing translations using the master branch

So now let us roll up our sleeves and do some real work! Assuming that you want to work with the translation of the current development branch, once you’ve checked out the module, you could start editing the messages catalog (your *.po file) using a text editor or any other graphical tool such as gtranslator or poedit.

I usually like to update the messages catalog template (*.pot file) first, followed by updating the messages catalog itself in order to have an up to date working copy. If I wanted to update the Brazilian Portuguese catalog, I’d run:

$ cd po/
$ intltool-update --pot
$ intltool-update pt_BR

Now that I have an updated message catalog I can start doing my work and translate whatever strings need to be translated or fix anything that is marked as being “fuzzy”. I could also take the work done by other collaborators and apply here, which is something I do quite often as I shall relate now.

You see, for those who don’t enjoy working with the command line or playing with versioning control systems, there is the “Damned Lies” system (or as I like to call it, “Djamned Lies” ever since it was ported to Django), a web interface that allows you to download the messages catalog and later on submit it back for revision and approval by someone with commit access. Damned Lies is much more than just a place to download and submit translations, as it allows for the administration of a team and lets registered users reserve a module for translation and request feedback when in doubt about the meaning of a word. So for this demonstration I will then reserve the Deskbar Applet for translation under the master branch.

I could then download the message catalog from the web site and start working on it, but as I already have the source code checked out, I used my local copy instead. After fixing the only 2 fuzzy strings remaining, I validated the format of my message catalog so as to make sure the file can be properly parsed and compiled, as well as not get yelled at! 🙂

$ msgfmt -cvo /dev/null pt_BR.po
357 translated messages.

Great! The file was validated and we can now submit it back via the web interface for revision and approval.

The moment I submit this file all those members from the Brazilian Portuguese team with commit access will be notified by email of the event. As I happen to be one of those with commit access, I can now commit my changes and push it upstream.

$ git commit -a -m "Updated Brazilian Portuguese translation."
$ git push

It is now up to me to mark Deskbar Applet as committed in Damned Lies and this way notify whoever submitted the translation that their work has been committed. I usually like to append the actual log message in the Comment field so that people can follow the commit if they so choose.

You could also send the translation back for more review along with some feedback and wait until the new translation comes back again.

Committing on behalf of someone else:

So far the example I used had only one player in the roles of translator and committer, but what if I had received a notification that Vladimir Melo, a fellow translator from the Brazilian team, had finished translating the Evince module and had uploaded his work waiting for someone to commit it?

To make things more interesting, what if he had worked in the GNOME 2.26 branch and not master as I had before? So let us first clone the Evince module:

$ git clone gnome:evince
$ cd evince

It is very important to remember that this time around we’re not working with the master branch, but the 2.26 branch (more specifically, the origin/gnome-2-26 branch as seen by running git branch -a). What that means is that you should then create a new branch that will clone the origin/gnome-2-26 branch in your current checkout.

$ git checkout --track -b gnome-2-26 origin/gnome-2-26

You should now have a brand new gnome-2-26 branch and should have been automatically switched to it:

$ git branch -a

* gnome-2-26 master

As I mentioned before, I like to make sure I have an up to date copy of the messages catalog template around:

$ intltool-update --pot

You then go to the corresponding page in Damned Lies (the notification email you get has the link for the newly submitted translation for Evince) and download the translation file, using it to replace the current message catalog in your checkout folder.

As different translators will use different text editors or graphical tools, I then like to handle issues that arise when lines get wrapped around and yield a much bigger delta due to the lines shifting around. In other words, I like my diffs to be as small as possible and only show what really changed! The magic incantation I use is:

msgmerge --update --previous pt_BR.po *.pot

Remember to validate the format of your final messages catalog file as well:

$ msgfmt -cvo /dev/null pt_BR.po
325 translated messages.

Now all there is left to do is commit the changes and push it through:

$ git commit -a -m "Updated Brazilian Portuguese translation." --author "Vladimir Melo <vmelo@gnome.org>"
Created commit 1535a8e: Updated Brazilian Portuguese translation.

1 files changed, 264 insertions(+), 194 deletions(-)
$ git push

Wait, have you noticed anything different in the syntax for this commit? The—author bit there is used when you are committing changes on behalf of someone else. Once my commit goes through, Vladimir will be credited as having done the translation.

One more scenario before wrapping up? What if you wanted to apply the same changes done in the origin/gnome-2-26 branch to the master branch? Easy! First let’s go back to the master branch and then “transplant” our changes to it:

$ git checkout master
$ git branch -a

gnome-2-26 * master

Now we perform the transplant:

$ git cherry-pick 1535a8e
Finished one cherry-pick.
Created commit 1535a8e: Updated Brazilian Portuguese translation. 1 files changed, 264 insertions(+), 194 deletions(-)
$ git push

“But Og, what the heck is the ‘1535a8e’ piece you added to the cherry-pick command?”, you ask. That is the revision number from the previous commit we did when pushing our changes to the origin/gnome-2-26 branch. If you forget this information, just switch back to the other branch and let git log show you the way.

Conclusion

Well, I hope that I haven’t lost you by now with this lengthy article, but if you’ve made it all this way and feel as lost as you were when you started, have no fear! Take a look at the documentation written up for translators or just ask someone in the mailing lists. You can also find me on irc hanging out at the #gnome-hackers channel on GimpNet and I’ll try my best to help you.

About the author

Og Maciel is a QA Engineer for rPath and a long time contributor to the translation efforts of several upstream projects. When not spearheading new projects or communities, he likes to fish, watch ice hockey and spend time with his 2 lovely daughters and wife in Chapel Hill, North Carolina.

Discuss this story with other readers on the GNOME forums.