Category Archives: January 2005

Getting Help from the GNOME Community

Ken VanDine takes you through how to obtain help for that one problem or issue in open source software that you don’t know how to resolve. Sit back, relax, and watch your problems go away!

 

There are many ways of getting help when it is needed. However, you will need to remember that all these methods are community driven. Everyone that you find help from is a volunteer, and they are helping because they want to. This community driven model has both advantages and disadvantages. The biggest advantage is that the support you get is from someone that cares, not a technical support representative at some big company that hates his job. The is huge, you will frequently find that you get more help than you ask for. The most significant disadvantage is the lack of a controlled, moderated environment. There is nothing keeping you from getting flamed or worse. Now, lets talk a little about how you get help.

Types of help

User Documentation

Of course, the first thing to do is look at the documentation. GNOME has a handy help application, Yelp. Usually found near the bottom of the application menu with a life preserver icon. I would recommend dragging that icon out to the panel for quick access, if you are just starting out. It will be your friend (even thou GNOME is quite intuitive). (TIP: Click and hold the icon on the Application menu and drag it to your panel and drop it). You can also view the user documentation at http://www.gnome.org/learn/.

Forums

Web based forums are probably the easiest way for most people to ask for help. A good starting point is http://gnomesupport.org/forums/. Web based forums allow you to simply search other people’s posts and the responses as well as post your own questions.

Mailing Lists

Mailing lists are also a great method, you will get answers to your questions right in your inbox. Mailing lists require you to subscribe to the list in order to post questions, some lists are very high volume, so expect lots of email. Another tip that will save you much grief is to ALWAYS search the list archives before asking your questions. List subscribers tend to get very upset getting asked the same questions many times. There is a mailing list associated with GNOME Support at http://mail.gnome.org/mailman/listinfo/gnome-list.

IRC

Internet Relay Chat has has been around for a long time. IRC will get you talking to someone in real time. IRC is channel based, so you log in and join a channel about the topic you are interested in. For general gnome questions, #gnome-help is a good starting point. To get a complete list of channels where you may get GNOME related help, http://gnomesupport.org/wiki/index.php/IrcChannels. For more general information on IRC, visit http://www.irchelp.org/.

Since most new users are probably not IRC gurus, I will briefly touch on basic IRC usage. Most Linux distributions include a pretty easy to use IRC client, XChat. It can be found on the Applications menu under Internet->IRC Client. When you first launch XChat, you will get a Server List/Preferences page like this:

In this pane, you will want to select the network you would like to join. For GNOME help topics, you will want to join GimpNet. You will also need to choose a nick name and two alternatives (in case someone is already using your first choice). Then simply hit connect. You will then get a general window with some server messages. The next step is to join a channel where you can chat with people. To join a channel, select Server->Join Channel from the XChat menu bar. You will be prompted for your channel of choice. For general GNOME help, join #gnome-help (all channel names start with a ”#”). That is it, you will now see a list of users in the channel on the left pane and the chat to the left. Your cursor is on the bottom, start typing.

TIP: Actions are fun, and usually enjoyed. You can specify an action by starting your message with a ”/me”. So, ”/me jumps” would display “yournick jumps” to the chat.

When leaving a chat, be sure to thank anyone that provided assistance and say goodbye. Remember to be courteous, just as if you were speaking face to face. Then select Server->Leave Channel from the XChat menu and the exit.

Wiki

Wikies are a great for of community documentation. A wiki is a web site that can be easily edited by anyone. That’s right, a free for all. So, as you figure something out that you feel may help someone else you can go to the wiki and add your experiences. You can of course also use it to search for solutions or ideas that can help you. The http://gnomesupport.org/wiki/ is a good place to start, and there are many others.

To contribute to a wiki, look for an edit link. There will usually be an Edit button on the bottom left of pages that can be edited. Editing does typically require you to register with the site, which is both painless and instant. You can also find links to wiki help on each page. The help pages will give you guidance on how to get around and formatting tips.

Helping out

Since all these methods require there to be people willing to help, I like to give back to the community I live in. So, therefore I do my best to help others that need assistance. You can do the same. As you get more comfortable using GNOME, you can actually periodically provide assistance to others. Check the forums from time to time and post responses, or login to IRC and see if anyone is looking for help. They would certainly appreciate a warm greeting and assistance. I actively participate in this community, I look forward to helping you out. On IRC my nick name is kenvandine and I hang out in #gnome-help.

Conclusion

As you can see there is a wide variety of ways to get support. You can browse local documentation with Yelp, search or post your questions to a web forum, subscribe to a mailing list, ask someone in real time via IRC, or even read community posted documentation on a wiki. Used effectively, you should always be able to get the help you need.

References

Discuss this story with other readers on the GNOME forums.

Advertisements

Galago – Presence for the Linux Desktop

Instant Messaging is becoming ever more pervasive in our lives today. Once upon a time, it was limited to geeks and a minority of our friends, but as we begin to connect with more people, things become much more complex. Christian Hammond explores the more subtle problems of Presence Management.

Introduction

Nearly everybody today uses an IM client to talk to their friends and family. Some even use it for discussions within their companies. Instant messaging has become an everyday part of life for these people, and have even supplanted the telephone for many uses. Thus we have the concept of Presence.

Presence

This article is not about instant messaging, per se, but rather about one key feature that makes instant messengers as useful as they are: Presence. Now, not everybody immediately knows what this is by name, but you’ve definitely made use of it. Presence is essentially the availability status of people. So, in your buddy list, a person’s presence may be that they’re available, away, idle, or marked that they should not be disturbed. These are just a few types of presence.

Presence, as it turns out, is useful even outside of instant messenger clients. Imagine going through your cell phone’s addressbook and being able to determine immediately whether or not someone is on the phone or if their phone is off. While we don’t have that capability on cell phones today, it’s something that you may very well see in the not so distant future. However, we are gaining this functionality in desktop computers. Soon, you will be able to go through your evolution addressbook and, based off information gathered from your IM or teleconferencing clients, you will be able to see who is available and who is not. Incoming e-mails will also provide an indicator, so if you really need to reach somebody immediately, you can choose the IM route over the e-mail one.

It’s all well and good to be able to integrate presence into various applications, but what about setting presence? Right now, when you get up to leave the computer, you have to set yourself away on any and all IM clients and other similar applications that you have running. It can prove to be annoying, and some elect to simply skip the whole process. In time, this will get easier. One single panel applet could set the desired away message on every capable program for you. It could even be intelligent and notice when you’re away from the computer and, depending on the day and time, auto-set the correct away message.

This all sounds great and fun, but someone has to write it. Fortunately, somebody is—me! For the past ten months, I have been developing a project I have named Galago. Galago is a project designed to provide presence to the Linux desktop. It’s a Freedesktop project, and thus is not tied to any particular desktop environment. However, as a GNOME user, I have a particular interest in integrating Galago into the GNOME desktop.

Galago Components

Galago uses D-BUS for communication. D-BUS is an excellent Inter-Process Communication library from Freedesktop. The two main components in Galago are libgalago, the standard library that projects will be working with, and galago-daemon, the D-BUS service daemon that provides the centralized management for presence. Since D-BUS is used, Galago can take advantage of D-BUS activation, so that galago-daemon is always launched when it’s needed. Users simply have to make sure that they have a working D-BUS session bus, and D-BUS takes care of the rest.

On top of those core components, there are other libraries and applications that users and developers may find useful.

libgalago-gtk provides a set of common GTK 2.x widgets for displaying presence information in the form of auto-updating service and presence icons, avatar icons, photo icons, service drop-down boxes, account drop-down boxes, menu items, and more. Once told to monitor an account, service, person, or presence, these widgets will listen in for any changes and update accordingly. This makes the developer’s life a lot easier, especially as the API is simple to use. gaim-galago is a plugin for the Gaim instant messenger client. It pushes service, account, person, avatar, and presence information to galago-daemon by using libgalago any time information on a buddy is updated. Currently, it only works with Gaim 1.0.x. Support for the development branch of Gaim (which will be 2.0.0) is not yet available, due to unfinished changes in that version of Gaim. eds-feed is a tiny daemon that is auto-launched by galago-daemon. Its job is to query Evolution through evolution-data-server and listen in on changes. Any and all person and account information is then sent to galago-daemon. galago-daemon is then able to take this information and better associate various IM accounts to actual people in your addressbook. gnome-presence-applet is an applet for your GNOME panel that allows you to easily monitor a set of peoples’ presences. Though the functionality is quite basic right now, it’s still very handy to those who don’t always want a buddy list on the screen. galago-sharp and galago-gtk-sharp are .NET frameworks that wrap libgalago and libgalago-gtk, respectfully. .NET apps, such as Beagle and perhaps soon Tomboy, can use these to work with the Galago framework in a much more natural way.

The Architecture

As mentioned above, Galago components communicate over D-BUS. However, applications don’t have to know that. Every application, galago-daemon included, talks through calls to libgalago. Or rather, by creating, destroying, and setting properties on objects.

libgalagodefines several key objects to work with: Account, Avatar, Person, Photo, Presence, Service, and Status. The two top-level objects are Service and Person. Everything else lives somewhere inside of them.

Every service, such as AIM, Jabber, or MSN, has a Service object defined. The Service object contains a list of accounts belonging in that service, as well as flags indicating how account names should be normalized (that is, whether they are case sensitive, allow spaces, etc.) for string comparison.

Persons represent an actual person, such as one defined in an address book. They also include properties for various things, such as the person’s first name, last name, address, etc. This is not meant to be a full replacement for the system’s addressbook, so this information should not be relied upon. Persons include one optional photo associated with it, as well as a list of accounts belonging to that person.

Account objects are for IM accounts, GnomeMeeting accounts, etc. An account has an optional avatar and presence associated with it. It has properties for the account’s username and display name, which should always be used in place of the username when being shown to the user. Accounts also contain a list of accounts (or contacts) that can be seen from this account. Think of the contact as a buddy in your account’s buddy list.

  • Photos are images associated with a person that contain a picture of that person, perhaps as defined in the addressbook.
  • Avatars are like photos, except they’re associated with an account and may look like anything. These are also known as “buddy icons.”
  • Presence represents a particular account’s presence information, such as their list of statuses and their idle state and time. Most every account will have a presence associated with it, but not all.
  • Statuses exist inside of a Presence. Each status represents a state, such as “available” or “away,” and may have properties such as an away message associated with it.

The object hierarchy uses a model similar to GLib’s object system, though much simplified. It doesn’t use GLib partially for political reasons with other desktop environments. However, the object system works very much like GLib’s, so developers used to GLib/@Gtk+@ programming will feel very much at home.

Many objects can be marked as being either native or non-native. Native objects are ones that were created by the local application, and non-native objects were retrieved from queries. Most developers will never have to know anything beyond that, aside from a few times in the API where a boolean ‘native’ flag is required.

Clients and Feeds

There are two types of programs that can communicate with Galago: clients and feeds.

Clients connect to galago-daemon through libgalago and query for information. The developer doesn’t have to do anything special to query for information, aside from calling a get function on an object and passing TRUE to the ‘query’ parameter.

Feeds push information to galago-daemon by way of libgalago. They do this by creating instances of objects and setting variables on them. That’s it. Feeds don’t actually have to know that a daemon exists. In fact, even if one didn’t for some reason, the feed would be okay. Due to the object hierarchy provided, applications may find these objects useful regardless, and would just feed to Galago as a side-effect.

Daemon vs. Peer-To-Peer

Many have asked why Galago uses a daemon model, citing that a P2P model would in fact be better. A daemon model allows for all presence, service, account, etc. information to be placed in one single location, making lookups fast. Rather than asking every Galago-enabled application if they have an account with a certain username and then filtering the results, only one query is instead needed. Furthermore, galago-daemon can intelligently combine the information from the objects it knows about and return the most likely correct information. For example, if three applications all claim to know presence for an account, but two claim it’s online while the other claims it’s offline, galago-daemon will assume that the online result is correct.

This is especially important when it comes to Person objects. Every account must exist in a Person, so a Person must always be created. However, in the case of such applications as Gaim, information on the person may not be available. In this common case, an empty Person object would be created. This information needs to somehow be associated with actual person information from an addressbook. galago-daemon achieves this by merging person objects when it determines that a merge is necessary.

Being a D-BUS-enabled daemon, galago-daemon can be auto-activated when first needed. The user doesn’t have to set anything up specifically to launch it or add it to the session manager. This model’s only main downside is that it takes more memory, although not much at all, yet it’s faster, more efficient, and easier to work with.

galago-daemonalso maintains a cache of person IDs. Unlike services or accounts, which have fixed IDs and can therefore be easily referenced, a person in real life does not have any such ID. Names are not unique, and not always provided. So the solution implemented in Galago was to generate a unique ID for the person and store it in a cache, along with a list of its accounts for later reference. Upon startup, galago-daemon makes an internal map of these IDs and retrieves the necessary information when requested later. Applications can then store a person’s ID with some certainty that it will remain available in a future session.

Future Possibilities

Presence on the desktop has a number of exciting future uses. Some will be available soon, due to integration with Galago. Nat Friedman’s Beagle project will be using Galago as a source for some of its indexing. Tomboy may add support in the future as well. Work is currently in progress to bring presence information to the Evolution addressbook and mail component.

One possible future use of presence would be a presence availability scheduler. This would keep track of the presences of people in the background and, when requested, would tell you the best estimate of when a person would be available next. So if you needed to talk to Jim Bob as soon as possible, you could consult the availability scheduler and find out, based on past activity, when Jim is most likely to be available next, and on what service.

Big Brother?

The major concern that has been voiced to me is that this information is really dangerous and that people would be able to start keeping track of people. Well, yes, they would be able to, but it’s no different than it was before. All of the information gathered by Galago is simply what was already available to you. It never leaves your computer, and it’s not put in some massive database. Galago is safe in such a way that 1984 wasn’t. If you don’t want people monitoring your presence, the solution is to not use services where they can do this. The possibilities on the desktop far outweigh the paranoia that will no doubt run rampant.

Conclusion

Presence technology will be a key component in desktop integration in the future. Windows will someday have it, according to some plans at Microsoft. Linux will soon have it by way of Galago. I suspect a number of very creative applications will be developed in the near future that incorporate presence information in new ways. See if you can think of any.

Discuss this story with other readers on the GNOME forums.

The Liberal Arts Major Test

Think an average Windows user would be comfortable in GNOME? John Meuser interviews a liberal arts major at Purdue University about her two year journey with getting to know GNOME.

Introduction

Around two years ago I started an experiment. Everyone seemed to be debating the merit of Linux on the desktop. Some pundits conducted the so-called Grandmother Test. They would get Linux installed and configured with an easy to use desktop (like GNOME), and see if their Grandmother with no computer experience can figure it out. I have never thought that this was a very fair test because someone with absolutely no computer experience will have problems no matter what desktop and operating system you put in front of them.

I also do not believe that putting a seasoned Windows user in front of a GNOME Desktop is a fair test either. They subconsciously expect things to work the same way they do in Windows, so the alternate behavior of GNOME usually frustrates them.

The best unbiased test would be to take someone who is more of a casual computer user. Someone who has enough experience to use a computer without much instruction, but has not used the same desktop enough to be pre-disposed to expect specific behavior. I also knew that this must be a long test in order to be accurate. Just because the user can fumble through for a few days with a Linux desktop, does not mean they can use it for an extended period.

A friend of mine matched the criteria perfectly. Jenn has been exposed to computers nearly all her life. She had a casual familiarity with DOS, Windows 3.1, and Windows 9x. She was by no means a techie, and at the same time wasn’t completely new to computers. I installed Debian with GNOME 2.0 on a machine that I built for her out of spare parts from an upgrade of my computer, and some salvageable parts of her old computer.

I sat down with her and showed her the basics of using it and figured out what programs she needed to use and showed her how to find and use them. Here is the list that she compiled of programs that she uses:

I generally handled the nitty gritty of the system like keeping it up to date and fixing little bugs that come up. She was able to transition into using GNOME very easily. The learning curve wasn’t nearly as steep as I thought it would be. She is able to learn to use GNOME just as easily as she learned to use Windows. After two years of using Linux, Jenn is satisfied with it as a desktop and encourages others to make the switch.

Interview with Jenn

GJ: What do you think of spatial nautilus?

Jenn: Spatial nautilus makes sense to me. Before spatial nautilus moving or copying files by means of the gui environment tended to be quite annoying. While manually searching through folders, if I came to a folder I realized I no longer wanted to use my first reaction was usually to close it, only to remember that I just closed ALL of the folders I was working with, and that I would have to start over. I do a lot of sorting through files and folders with all of my music and pictures, and this spatial method makes it so much simpler for me.

GJ: What was the hardest part about the switch from Windows to GNOME?

Jenn: I had purchased a webcam right before the switch. It just happened to be the one webcam that no one had developed drivers for. I went through serious Sims withdrawal, but that can be prevented by having a windows partition. It took me a short time just to get familiar with things. I can be pretty impatient when it comes to technology, I want things to work, my way, now. I find that I am more able to do this using Linux, however in the very begining it was hard for me to see this. If you decide to make the swich, the best thing to do right after installation is sit there with a guru and just do what you typically do in front of your computer. After that you can tackle the bigger stuff.

GJ: What was the easiest?

Jenn: Before my swich to GNOME, I was already familiar with the essentials; Gaim, Evolution, and at the time Mozilla. So that change was no big deal. When I learned how simple it was to find and download new programs, that was pretty easy too, however for some reason I really struggled a bit with actually installing new software.

GJ: What do you like about GNOME?

Jenn: GNOME makes it possible for me to do what I want to do on my computer, without a lot of hassle. Its sleek, simple, and very very sexy. It doesn’t go out of its way to make me feel like a preschooler.

GJ: What don’t you like about GNOME?

Jenn: I actually had to ask my friend what I don’t like about GNOME. I honestly can’t think of anything . . . really. 🙂 Maybe just that I can’t play most videogames.

GJ: Describe your experience when you are forced to use Windows now.

Jenn: Anymore I find using windows to be obnoxious and annoying. It seems like every time I use a windows machine in labs, or if I use my friends’, there are these incessant boxes recommending you do stupid things, like remove unused icons. If I wanted those icons removed, I would have done it myself.

GJ: In your opinion, do you think that GNOME is usable by non-techie users?

Jenn: GNOME is definately usable by non-techie users. I would recommend having someone experienced around to help through the transition. I think a lot of people who find they don’t like using GNOME simply haven’t seen all that you can do with it, or you like KDE for some reason. 🙂

Conclusions

My experiment has been a success so far. I have reciently moved her over to Ubuntu from Debian which is working very well for her. Since stability is not the focus of Debian Sid, bugs tended to crop up occasionally after upgrading. This made periodic upgrading something I was not comfortable with her doing on her own, so I did it. With Ubuntu, you get a stable, up-to-date desktop with fewer updates between releases, so I believe she should be able to administer it on her own.

I believe this two year experiment shows that the GNOME desktop is definitely user-friendly enough to be used by the average user. The administration side of Linux is not quite ready for the Liberal Arts Major, but Ubuntu is making some fairly large strides in this area.

Discuss this story with other readers on the GNOME forums.

CD/DVD creation with Nautilus

In this first article by a new writer to GNOME Journal, Ken VanDine covers everything you need to know about burning data CDs or DVDs using Nautilus. If you’re looking for audio CD burning in GNOME, fear not, for we plan to cover this topic in a future GNOME Journal release.

 

Introduction

In the past burning CDs or DVDs has not been a task for the inexperienced Linux user. Depending on hardware, one would have to pass boot arguments or compile custom modules into the kernel. This isn’t the case on a modern Linux system. In fact, if your system has a 2.6 kernel, it should work right out of the box; no tweaking, rebooting, or hair pulling. For those of us who use Gnome, burning CDs or DVDs is very simple. This article will cover creating data CDs or DVDs using tools that every Gnome user has. In the next edition, we will cover creating audio CDs.

Step-by-Step

Gnome’s integrated Nautilus makes CD/DVD burning simple. I recently stumbled on this powerful feature. For years now I have been using the command line tool, cdrecord. It is a great program, but not trivial to use. In fact, Nautilus uses cdrecord to handle the burning, it just provides a simple GUI. With Nautilus, it is as simple as drag and drop. Here is how!

First, insert a blank CD/DVD in the writer. A window like this will popup:

Drag the files you want to burn into the empty window like this:

When you have selected all the files you want on the CD/DVD, select file from the menu and choose “Write to Disc”.

You will then get a simple dialog like this one:

Update the Disc name to something meaningful, if you like and hit “Write”. When the disc is complete, it will eject.

Here is another little tip. To create an autorun script, create a plain text file named “autorun”, something like this:

#!/bin/sh dir=$(echo $0 |sed ‘s/autorun//’) cd $dir fullpath=$(pwd) exec /usr/bin/nautilus $fullpath

To make it executable, right click on the autorun script and set it to executable.

Drag it into the burn window with the rest of your files. Now, when the CD/DVD is inserted a new nautilus window will open and browse the CD/DVD.

How about creating a CD/DVD from an ISO file? Simple, using Nautilus, browse to the desired ISO file and right click on it.

You will notice an option called “Write to Disc…” at the bottom of the menu. Select that and burn away.

That’s it! You are now an expert at CD/DVD creation with Nautilus.

The Future

As most of you may have noticed already, Linux is evolving very rapidly. In fact, development of Linux and Linux tools have progressed at an astonishing rate. As good as Linux is today, the future is even brighter. Hardware support and integration are getting pretty good, and there are several projects that will make dealing with hardware a breeze. From a CD/DVD point of view, there is a project called libburn that has been adopted by the freedesktop.org group. The intention of libburn is to abstract the process of burning CDs and DVDs from the applications allowing all applications to burn. This will provide consistency, better error handling, and broader support.

Discuss this story with other readers on the GNOME forums.

Working with Remote Resources

A modern desktop needs to be able to communicate with network resources over a wide range of protocols. Jorge O. Castro shows how to connect to these remote resources and use them transparently in your day-to-day work.

Introduction

In today’s connected world, users find themselves managing data on any possible number resources. While keeping data on a local filesystem is still the most commonly used method of accessing files, we are increasingly using networked resources as a means of sharing and backing up data. A typical case would be a web developer copying his/her pages over to a web server using an FTP or WebDAV client, or perhaps copying them over to an SMB share on the corporate network. While these methods work, GNOME offers a transparent method of dealing with these networked resources that makes dealing with them as simple and easy to use as the local filesystem.

Let’s Get Connected

Utilizing these GNOME VFS features takes minimal effort, everything is provided for you out-of-the-box. Once you learn how to use remote resources in this manner, you’ll find them a valuable tool in getting work done. First, let’s access the connection dialog, you can do this by selecting File, and then Connect to Server from any file manager window.

Connect to server

From this dialog we can connect to any remote host via a number of protocols. If you are on a LAN and are unsure of what host you need to connect to, you can click the Browse Network button and see what servers are available on your network.

To connect to specific hosts, you can choose which protocol to use by choosing one via the dropdown, and then filling out the rest of the
dialog:

Connect to a Samba share

Let’s start with something simple, like accessing a remote shell. We’ll use this as our first example, using ssh. Since the actual protocol is just an option, you can apply this technique to FTP, WebDAV, or Samba. Fill in the login credentials, and for Name to use for connection, you’ll want a friendly name, since Nautilus will name the shortcut after whatever you put in there. After everything is filled out, just click Connect. GNOME will then display a new icon on your desktop:

ssh desktop shortcut

What GNOME has done here is taken your remote host, and “mounted” it onto your desktop. You can now open this folder, and manipulate files and directories as if they were on your local machine. If you’ve already setup password-less authentication via ssh, then GNOME will respect those settings and never prompt you for a password, otherwise, it will utilize the keyring feature to keep all your remote passwords in one place, accessable via your keyring password. One thing to consider when doing this is the speed at which your network is in, there might be a considerable delay depending on network conditions.

You can have as many desktop shortcuts to these remote hosts as you need. The icons themselves have labels which remind you what protocol you are connected to, so you can have multiple kinds of connections to the same machine. For example, when I am at work with my laptop, I connect to a certain host via SMB since I am on a LAN. I also have another shortcut, except connected via ssh, so when I am on a foreign network I have a secured connection.

Another useful feature is that with multiple shortcuts you can drag and drop files between two remote hosts rather quickly, regardless of what protocols those hosts use. But GNOME doesn’t just put an icon on the desktop, the ideal goal is for this transparency to apply to all applications. GNOME applications take advantage of this via the file dialog.

ssh desktop shortcut

As you can see, the desktop shortcuts have also been added to the dialog box. In this example, I’m using screem to save files on my remote host. It is important to note that I do not need to set this up on an application to application basis, GNOME applications will merely pick up the new shortcuts as you add them. A caveat is that not all applications take advantage of this new dialog just yet, but most of them do. I can, however, work around that issue by saving the file locally, and then dragging it to the remote folder.

Once you’ve set up folders to your most commonly used network resources, you’ll find that they become useful and will save you time in the long run. This is especially true if you use multiple machines, or a laptop, since the shortcuts remain on your desktop across sessions. Future developments, such as command-line tools will allow for even greater functionality, such as scripting these shortcuts across a deployment, for example.

Resources

  • For more information, you can scan this chapter in the Gnome User’s Guide. (Note, this documentation has not been updated to include Gnome 2.8, but it is still useful)

Discuss this story with other readers on the GNOME forums.

Experimental Culture

In this opinion piece, Seth Nickell discusses the culture surrounding GNOME, where the culture has been, where it is now, and where he thinks it should be heading towards.

Introduction

In 2002, Derek Glidden wrote a humorous comparison between his visions of how GNOME and KDE development occur. Just to give you a taste:

”[KDE is developed in] a big room somewhere in Europe with lots of chrome and glass and a great big whiteboard in the front with lots of tiny, neat writing on it. There are about 50 desks, each with headphones and pristine workstations, also with a lot of chrome and glass. The faint sound of classical music permeates the room, accompanying the clicky-click of 50 programmers typing or quietly talking in one of the appropriately assigned meeting areas.

~

”[GNOME] Development strategies are generally determined by whatever light show happens to be going on at the moment, when one of the developers will leap up and scream *‘I WANT IT TO LOOK JUST LIKE THAT’* and then straight-arm his laptop against the wall in an hallucinogenic frenzy before vomiting copiously, passing out and falling face-down in the middle of the dance floor. There’s no whiteboard, so developers diagram things out in the puddles of spilt beer, urine and vomit on the floor.

I would argue it was already an in accurate caricature when it was written, but was spot on only a year or two before. When I first read that page, on balance, I thought it made it sound better to be a GNOME developer than a KDE developer. At least GNOME developers sounded creative and lively.

Today, I would argue that the caricatures are almost reversed. GNOME is a paragon of usable, restrained, unimaginative, corporate development. KDE is lively, nimble, cluttered, and a little crazy. What happened? How can we get the good aspects of “old GNOME” back without returning to diagramming in puddles of spilt beer, urine and vomit?

~

It was not so terribly long ago that GNOME was a bastion of unfettered development. We focused on possibility rather than our (at the time quite serious) inadequacies. And it was good for the project: GNOME was an enthused development community. Features were slammed out by the likes of The Dark Prince, seething pits of free software development, hyperactive Mexicans, and cowboys. Even her royal majesty the Queen of England got into the game by maintaining a module or two. Sure, Enlightenment came onto you like a drunken whore, her makeup blotchy and fluorescent, but man was it cool.

New applications were added by the crate load. Maintainers took almost any UI change, as long as it came with a patch and added a neat feature. Libraries were under constant churn as fresh widgets, features and utility functions were crammed into gnome-libs. Occasionally the features were completely broken, sometimes the new APIs were confusing or incomplete, and usually they had a host of egregious usability problems.

The result? GNOME was a great experience for developers and, at best, a chaotic experience for any hapless user who cared about getting something done. Having a motivated developer community is very important, particularly to a free software project. But if that community is not producing relevant, user-focused software its nothing more than a fun party, and we were falling short on this point.

A New Approach

In recognition of this problem we steered a new cultural course for GNOME. Restraint, thoughtfulness and usability were defining characteristics of this new culture. These are very important qualities for targeting desktop end users. Most of us didn’t (at least, I didn’t) think of it as building a new culture at this point, but simply as a new set of practices. But new practices tend to foster supporting changes in their host culture. I think there can be little doubt in hindsight that GNOME underwent a major cultural change.

We accomplished a major cultural shift in record time partly by open hostility toward the “old ways”. This wasn’t a planned thing just a natural reaction to getting past ingrained ways of thinking. Projects (and to a lesser extent, people) who didn’t get on board with the new agenda or represented the old ways of thinking were mocked. This is actually pretty typical of major cultural changes: “culture wars”. The only surprising aspect of our cultural revolution was that a great percentage of the old crew stayed with us – typically a major cultural shift represents a change in people.

Inconveniently, prior to the cultural revolution, we had picked up a following of users who themselves appreciated the fruits of the old ways: churn and toys to fiddle with. We learned to avoid the natural tendency to develop for these users by marginalizing them; ironically the users who were most enthusiastic and present on mailing lists, irc, etc. Its easier to avoid developing for somebody when you can call them a “crack smoker”. It protects you from the reality that you have dismissed the core interests of a person or group of people. Dismissing these “crack smoking” users hastened the transition, made it easier, and that’s a probably a good thing. The bad thing is that we perpetuate these irrational emotional responses, but more on that later.

On a more positive note, the new course wasn’t just a blood bath. In conjunction with these attempts to reject the old we were experimenting with new social infrastructure (e.g. the release team), equipping ourselves with new techniques (e.g. targeting classes of users and evaluating our software relative to them), and building tools to support our new methodologies (e.g. the HIG).

The results were good. Very good. Applications behaviors grew more predictable as they were standardised. Clutter and excess were trimmed down, making features available to a wider body of people. Releases came out with the regularity that can only result from a high-fibre diet. Development was user focused.

~

Somewhere along the line our process, usability and thoughtfulness constricted us such that we forgot how to appreciate new ideas. With it went a lot of our enthusiasm. When people come into a mailing list or IRC channel with a quick implementation of an off-beat idea, droves of righteous knights rise up to slash them down and set fire to their bodies. Their steaming corpses serve as a warning to others. Our knee-jerk reactions to protect ourselves from crazy features and unfocused development served a purpose in the glorious revolution. Their time is over, the revolution is over, we need to learn how to move on.

The original problem wasn’t the freedom to experiment. The problem was shipping all the experiments. How do we encourage wild ideas and interesting features without producing an incoherent overall product? Right now the badge of social approval in GNOME is “ships as part of the release”. We can, and should, value trying things out. They might work, they might need refinement, more often than not they won’t work at all all. So what? If you don’t do things wrong you’ll never do anything new. GNOME hackers seem to have developed a hesitance toward writing code they aren’t sure will pan out. We have this perfectionist streak that results in stagnance. Further, we as a community have become quick to discourage ideas or development that are slightly off. That means good things are often killed in infancy, rather than aiding in taking something that’s slightly off and making it work.

Its as if we fear cranky features appearing in our releases. No doubt, it is easier to kill an idea by being vocally and strongly against it. But perhaps we can we find a way to send this message instead: _“That is a really cool idea. Its definitely experimental, and I suspect it won’t make it into a release in that form, maybe not in any form, but its great you’re working on it and I’d love to help out.”_

This is not without precedent: most large companies do a lot of “research” (or more applicably, product prototyping). They don’t productize most of the designs coming out of research groups, but they encourage them, and ideally latch on to the viable ideas and push them into products. There’s nothing wrong with thinking something is an interesting idea, but still a stretch. Its not just encouraging other people (though that is important too). We, as a community, need to be more willing to prototype interesting concepts without an expectation or need for them to show up in a release.

This is not to say that we need to respect and treasure every idea that gets bubbled to the surface. Most ideas proposed by random people on mailing lists are still as questionable as they always were. We still need to keep the signal to noise ratio high. That means we still need social means to filter out the droves of unwashed who appear naked at our door with naught but a mad idea clutched in their fists. We would be swamped if we didn’t. Research doesn’t mean “anything goes”. It doesn’t mean you can’t separate crap from ideas that are based on good insights. It means you look for an interesting core in a troubled prototype. It means you dive ahead with something when not all the details are clear.

Its not like we aren’t doing some of this already. There are a number of interesting projects going on right now with various degrees of experimentation (beagle, luminosity, tomboy, gDesklets, etc, etc). Some of the related/peripheral communities in GNOME are already much better at this, notably the pygtk and gtk# communities. On the one hand, its easier to prototype software in python and C#. But another effect might be that by and large people writing in these areas aren’t thinking about “how do I get this in GNOME”, if only because of the still extant natural resistance to non-C applications in core GNOME. It leaves people more free to experiment. That in turn promotes a culture in these communities that is open and encouraging of experimentation.

Conclusion

We need to get back some of that old-school madhouse charm, not only for our own interest and sanity, but also for the good of the product. We need both offbeat experimentation and stodgy conservatism in order to improve. Right now we’ve got stodgy conservatism down pat, lets branch out and figure out how to appreciate both. Hug an inventor near you, especially if its yourself.

Discuss this story with other readers on the GNOME forums.