Category Archives: April 2006

Three Simple Tips for Interface Design You Should Know

The GNOME Human Interface Guidelines (HIG) have always been a controversial topic among fans and third-party developers. Claus Schwarm shows you why the HIG is important and some subtle ways in how to utilize the HIG in simple but not always obvious ways.

When the GNOME projects’ members started to work on version 2 of the GNOME desktop environment, no change produced as much aversion, displeasure, and anger as the Human Interface Guidelines (HIG). Still today, some complain about the current direction of GNOME.

There is no such thing as a perfect guideline—at least, not when written by humans. Mistakes happen. The interpretation of usability principles may lead to wrong or inappropriate conclusions—inappropriate because development is done in special circumstances, carried by volunteers and enthusiasts.

However, very fundamental ideas of the HIG don’t need to be discussed in the light of usability principles, alone. In fact, such a discussion may be misleading: Many people seem to confuse the word “usability” with “being used to”, and thus argue for whatever they already know. But you can’t conclude from one observation to the general rule. It’s a classic failure in human thinking.

The HIG is not just a collection of usability principles, it’s also a sort of unofficial standard. It’s sufficient to accept them as such. Just like many states in the world decided to drive on the left side—which is obviously wrong when you’re from a state with right-side driving—, this is not a question of wrong or right, or good or bad. The central question is whether everybody drives on the same side in a particular country.

A pragmatic approach to the GNOME HIG is thus: who cares whether it’s left or right? Right or wrong? When in Rome, do as the Romans do.

GNOME’s interface toolkit, GTK+, and all of its numerous language bindings imposes nearly no restrictions on the interface design. And with freedom comes diversity. The GNOME HIG may serve as a way of coordinated efforts; a tool to avoid unnecessary diversity. It’s a friendly and useful meeting point, worth revisiting every few months. The following three simple recommendations aim to provide a basic starting point for developers and interface designers.

(1) Get your Window Types Straight

GNOME’s Human Interface Guidelines distinguish two types of windows: primary and secondary windows. Primary windows are the main windows, those that hold the contents a user cares about.

There are quite different kinds of primary windows: for example, gEdit and Mozilla Firefox use a single interface with tabs inside, Inkscape uses a single window interface with multiple instances, and GIMP uses a multiple window interface. Which type of primary window you should use depends on what audience you’d like to serve. The choice is rather specific to your situation.

Less specific is the design of secondary windows. They do not present content that is central to the users. All applications have lots of secondary windows except maybe the most simple ones. Here, most application developers can improve their interface design easily, and without much hassle.

Often, all secondary windows are called dialogs. This is convenient but a little bit misleading: the GNOME HIG uses the word in a specific way. It differentiates five types of secondary windows:

Mixing these types, or rather, their design elements, is a common error that leads to unnecessary work and ends up creating confusing interfaces and confused users, even if they wouldn’t admit that.

What are these design elements? Common to all secondary windows is a certain window type, and buttons for interacting with the window at their bottom. Common is also the question whether they have window titles, show up in the window list of the panel, and whether they use a certain layout for the text. However, depending on the window at hand, these elements are used differently or not at all.

Type Window Title Primary Text Panel List
Utility Windows Yes No No
Dialogs Yes No No
Alerts No Yes No
Progress Windows Yes Yes Yes
Assistants Yes Sort of Maybe

The above table makes is easier to spot the basic differences between these types. For example, the design of utility windows and dialogs could be called a reference for secondary windows. Alerts, and progress windows seem to differ from the reference.

A utility window layout is usually used for windows which display document or application properties or preferences. GNOME’s default editor gedit, for example, has several utility windows: “Edit > Preferences”, “Tools > Document Statistics”, or “Help > About”. A dialog window, on the other hand, is needed by the user to complete a certain task. Again, gedit has several examples: “File > Open”, “File > Save”, “File > Print”, or “Search > Find”.

Utility and also dialog windows are usually not meaningful to the user without the parent window. Thus, there’s no need to display them in the panel list of windows. They are also usually requested by the users; their appearance is no surprise. Thus, they usually do not need deeper explanation; there’s no need for a primary and secondary text. It’s sufficient to use a window title.

These assumptions break for the other two important window types: Alerts and Progress Windows.

Usually, a user doesn’t request (or want) any of them. An alert is obviously alerting him/her that something important has happened. From the user’s perspective, this is a surprise. It requires an explanation. Thus, primary and secondary text make sure that a user understands what happened. For a similar reason, progress windows are not wanted by a user either: Users expect that everything happens immediately. The need to wait for the computer is a distraction. Again, a primary and secondary text makes sure the users understand what’s happening.

But there is a slight difference between alerts and progress windows, namely how users react about them. An alert is usually read and closed fairly immediately. There’s no need to use a window title or make it appear in the panel list of windows. Both elements would be distractions for something that will exist for only a few seconds, anyway.

But the best reaction about a progress window is to do something different. There’s no way around to speed up the actions. Thus, progress windows do appear in the panel list and they do have a window title. Users must be able to identify them if they decide to care about a different task while waiting.

The remaining window type mentioned by the HIG is “Assistants.” It’s the most simple type: there’s not much to learn about it—just try to prevent using it by all means. If, after careful consideration, you see no other way than using an assistant, GTK+ 2.10 and higher will provide a simple widget for it.

The first four window types in the HIG can thus be separated by the role of the user: Is he/she active and the window was requested? Or is he/she passive and the software needs to display the window? In the first case, you will need a utility window or a dialog, in the latter case an alert or a progress window.

Mixing these types may lead to a confusing user interface. When mixing an alert and a utility window, you will just repeat information. This may look like this:

A more complicated case is to mix a utility window and a progress window. This may lead to an unusual combination of buttons in the window, confusing the user and letting him/her lose control. A good candidate for such a mix is a search dialog: People need to enter information before the search is started, and it may last a few seconds.

There are two simple ways out of such a situation: First, you can turn the single window into two windows: the first being a usual utility window which is shown until the users selects an appropriate option. Then, hide the window from the view, and show a usual progress window until the requested action is finished. Another option is shown by GNOME’s default search utility available under “Places > Search for files…”. Here, the default action is changed during a search while a small icon indicates ongoing activity.

(2) Order Buttons and Label them Appropriately

With the notable exception of toolboxes, all secondary windows should have at least one button. All button labels should use an imperative verb describing what it will do when clicked. The button with the suggested (or affirmative) action should be in the lower-right corner. This is probably the most discussed recommendation of the HIG.

Again, it’s not relevant whether it’s good or bad, wrong or right, or right or left: When in Rome, do as the Romans do.

However, users running HIG compliant applications under GNOME probably noted that it’s usually a snap to get rid of windows, in general. It takes nearly no mental effort. One reason may the above rule: Your “muscle memory” is used to the fact that the most appropriate action is always in the right corner. Funny enough as it seems to be unaffected by the fact that the window is mostly somewhere else on the monitor screen.

Car drivers who are used to a manual transmission know a similar effect: After the initial training, they don’t need to think about switching gears, anymore. The movement is prepared without your consciousness being involved. Getting used to a affirmative button in the lower right corner is even more simple.

But that’s not all. The rule also helps developers: If you have trouble finding the affirmative action for a certain secondary window, you probably need to step back a second and think about your window design again. You have probably made a mistake, and didn’t respect the first tip mentioned above.

If, for example, the developers of the above “Create thumbnails” dialog would have used the affirmative-action trick, they would have noted that something’s wrong: First, you certainly don’t call a dialog to close it right away. You want to do something, first. The button order “Stop”, “Close”, and “Start” would have made more sense. Next, the affirmative action is “Create”, not “Start”. With the affirmative action in the lower right corner, the developers could have saved their time including an extra element which explains users what to do: “Click Start to begin.”

Additionally, they could have made the Enter key trigger that button—a general recommendation for all alerts, dialogs, or assistants with an affirmative button for continuing. The only exception to the rule is when hitting the enter key by mistake would cause a lot of damage: Think “Erase Disk”.

Why does it matter how buttons are labeled? Using verbs helps you as a developer to formulate the question correctly. This is also useful for developers without English as their native language. Even native speakers have proven in the past that it’s easy to formulate sentences which are easy to be misunderstood. However, a verb makes using a dialog more easy. In contrast, see the following screenshot where the meaning of the answer depends on a single (hidden) word in the dialog text:

You can probably guess the hidden word. But are you sure, it wasn’t “Cancel?”

(3) Layout with Spacing and Alignment

Screen real-estate is scarce and developers like to put many functions into an application. As a result, an increasing amount of elements share a more or less fixed amount of pixels. It’s getting crowded. To separate distinct elements, developers add even more elements, and thus more visual noise to a window layout.

In contrast, the GNOME HIG recommends to use a multitude of 6 pixels for layout. For example, use a 12 pixel wide border in a secondary window. In Glade, this is done by using a 6 pixel border for the window, and a 6 pixel border for the inner content. With buttons labeled as discussed above, the result may look similar to the following dialog window:

It’s a simple construction. The usual separator between the lower buttons and the content is disabled as recommended by the GNOME HIG. One thing becomes immediately obvious: The design is not yet relaxing. However, it exemplifies some principles of laying out utility windows and dialogs.

The layout uses a vertical box with 3 rows to layout the inner contents. The spacing is set to 12 pixels so each part is visually distinct. A frame is used in every row, with its borders set to “none” and its label set to be bold. Of course, it’s also necessary to add the borders around the final buttons.

Within each frame, an alignment helps to layout the inner contents. Use 12 pixels for the left padding, and maybe 6 pixels for the top padding. That’s it, basically. Try to align the inner contents to the left and to the right, if possible. For instance, this could be done to the combo box that is used to select the units.

Overall, it’s a really simple design. It copies the “Export to bitmap” dialog used in Inkscape 0.42. Here’s, how it looks:

No interactive element was removed. Everything’s still there. Applying basic HIG design recommendations is thus possible without removing functionality, and the necessary effort is not even overly demanding. However, it improves overview for users—probably not just for those living in Rome.


Following these simple three recommendations will not make an application easy to use, or usable. They may help you to get started on making your applications more usable or easy-to-use, though. However, they certainly do no harm, unless you consider it your personal goal to make a platform such as Microsoft Windows more consistent and successful.

The GNOME HIG offers a lot of advice in making applications more usable. Some of them are useful in all situations—for example, you probably like to remove all computer jargon in your application, a hard to reach goal. Some may need a second thought whether other considerations are more important in a certain situation. Applications designed for professionals—people who work all day long with a certain application—probably need to take special care about efficiency as well.

When in doubt about the usability of a certain design, the GNOME usability mailing list is always there to help. There’s also an IRC channel #usability on to ask, although it doesn’t appear to be very active. It’s not a failure to get help from designers. This is maybe the most important recommendation of the GNOME HIG.

Discuss this story with other readers on the GNOME forums.

Behind the Scenes: Elijah Newren

Continuing with his series about people who contribute to GNOME, Lucas Rocha interviews Elijah Newren, the GNOME release manager. Elijah talks about computational biofluid dynamics, Metacity and other GNOME topics.

Short Intro


In what ways do you contribute to GNOME?

First of all, I intentionally write it as Gnome, and will continue to do so. Five letters of all caps just sucks. Concerning your question: I contribute to Gnome in a few different areas. I’ve triaged a huge number of bugs, though I’m still a far second to Gerardo and have concentrated more on other things recently; I assisted with the last Bugzilla upgrade and continue to work on random odds and ends to improve Gnome bugzilla (though I successfully avoid the hard work like the stuff that Andrew did for 2.16 and Olav did for 2.20); I wrote a tutorial on developing with Gnome covering just some very basics of getting started that someday I hope to get back to and improve; I’m a member of the release team (the least clueful one); and I’m co-maintainer for metacity and libwnck. You can find slightly more details at, which isn’t horribly out of date.

How and when did you get involved in GNOME?

David Richardson, a friend of mine, introduced me to Linux in 2000/2001 after I complained about how Windows was useless for getting work done and how I’d like to have something Unix-like at home. (I had heard of Linux before that but only in passing; I’m not sure how I missed it so thoroughly though…what world was I living in?) Over time, I got addicted to learning more about the system and then moved on to wanting to contribute back. The kernel seemed like it already did everything I wanted, so I figured I’d help one of the desktop environments. Choosing between KDE and Gnome was a tough call for me at that point (and I mulled it over for a few weeks and read up a little about both), but I eventually showed up to a few of Luis’ bug days in 2002 and the rest is history.

What motivates/keeps you motivated to work on GNOME?

An awesome community with many cool friends, the knowledge that my improvements are benefiting huge numbers of people’s daily lives, and lots of itches to scratch. 😉

How much time do you usually spend on GNOME?

Pretty much all my free time that I don’t spend with my family. 🙂

What do you think is still badly missing in GNOME?

Market share. 😉 I’m appalled that Microsoft still has such a large installed base.

In your opinion, what should be the next GNOME big steps?

Personally, I’d prefer taking small steps; I really like the “evolutionary, not revolutionary” mantra. We have too many long standing bugs that deserved a much shorter lifespan than what they received.

What is the relation between computational biofluid dynamics (your doctoral research) and GNOME? Which one is more challenging?

There really isn’t any relationship. I’d definitely have to go with computational biofluid dynamics being more challenging. I’m really excited about the paper that we just submitted on “Unconditionally Stable Discretizations of the Immersed Boundary Equations”. That’s one outstanding problem solved in the community, and I think it’s going to lead directly to one or two others too.

Since this is a Gnome-ish interview, though, let me point out some of the strong advantages it has: (1) working with lots of cool people (my doctoral research has been predominantly an individual effort, which has not been to my liking; though luckily it is changing now), and (2) the fact that Gnome affects millions of people’s lives for the better. (My current research results will mean nothing to anyone outside a small group of researchers in the short term; and it’s hard to predict the long term effects; however, since I am more interested in the tools than the particular scientific application, this is something that can change—but it still won’t be on the scale of Gnome).

You’ve taken on a huge responsibility with metacity – how do you keep things interesting for potential contributors, while sticking to the “should be like Cheerios” design goal?

Back when I was just getting into Linux & Gnome, I remember going to try to change something and seeing what turned out to be the Sawfish configuration dialog. I had this huge awful feeling that it’d take forever just to master even this part of the desktop, and wondered how I could ever even become proficient as a user of the system if that were the case. That may sound stupid (especially considering my Unix background) because I really didn’t need to look through many of the configuration abilities of sawfish or understand what they were. But I didn’t know that and it made me feel both overwhelmed and not in control.

That said, I don’t think Metacity is really quite like Cheerios. I think Honey-Nut Cheerios is a more apt analogy. If Metacity really were like Cheerios, sloppy and mouse focus would not be part of it as they open up a tremendous can of worms that take an awful lot of maintainer time. Of course, without sloppy and mouse focus, I wouldn’t use Metacity and I am quite certain that all major distros would patch or fork it. So there’s a tough balance.

The balance is made tougher because, as Havoc points out, Gnome (1) doesn’t have an official target audience, and (2) has no real direct distribution channel of its own. Because of the second point, and the fact that all the linux distributions (and BSD variants and Solaris and others) are currently tech-user-oriented, any decisions we make can easily be vetoed. My personal opinion is to try to draw a tough line, and relent in the cases where our decision is almost unanimously overriden (see bug 326156 for an example of that happening). Of course, allowing our decisions to be overridden actually matches the rationale behind features in Metacity (see the tail end of So, I’m probably not doing a perfect job, but that’s where I’m aiming right now.

Which distribution do you use? Why?

Fedora. It’s better than all the others. 😉

What is GNOME’s killer app? Why?

Well… gnome-terminal seems to be the one most appreciated by other students in the math department here when I’ve helped them get Linux installed. “It’s the best of both worlds—a really easy to use interface like Windows and you still have the command line like Unix for getting work done. And it’s so cool that the terminal has multiple tabs.”

But, for the non-niche userbase out there, I think part of the comments of even these specialized users is revealing—it’s the easy to use, non-overwhelming interface that makes Gnome rock so much.

Who are your favorite GNOME hackers? Why?

There are way too many to list, even if I were to try to limit it to people who work on areas closely related to what I do in Gnome. It’d be really difficult to pick out favorites. Just listing ones off the top of my mind there’s bkor, kmaraas, ssp, mclasen, markmc, seb128, federico, jrb, owen, vuntz, clarkbw, fatalerror, crispin, luis, aes, murrayc, halfline, davyd, fer, smitten, ninja, calum, and I’m sure I could go on and on. I’m in awe of the many people who kick butt working on Gnome, often times with very little recognition compared to all the heavy lifting they do.

What does your desktop look like?

It still looks pretty much like this:

It’s a screenshot I posted on my blog about a year ago when everyone else was also posting screenshots.

Well, okay, so I really don’t see that background all that much with dozens of (Gnome-)terminals, a few evince windows, a few emacs windows, a couple mozilla windows (yes, with lots of tabs just like all the terminal windows), evolution, and maybe xchat or another app spread among 4—8 workspaces.

Who or what in your life would you say influenced you most?

I totally lucked out in getting the most awesome parents in the world. Probably like most kids, I wanted to be just like my dad when I was little; but I still felt that same way through most of my teenage years. Becoming a parent myself has made me appreciate them even more. It’s too bad they got the short end of the stick. 😉

How would you describe yourself?

I probably wouldn’t, except in answer to others’ questions. So, uh, take a look at the answers to the other questions in this interview. 😉

What do you get passionate about?

My family, solving cool problems, the restored gospel, GNOME, FLOSS in general.

What sites do you visit daily?

Planet Gnome, Linux Weekly News, Google, Gmail, Gnome Bugzilla. Footnotes used to be one, but they’ve allowed trolls to mostly overrun the place to the point that the only reason for core contributors to visit is to provide some counterbalance to what hapless newbies might run into; its continued existence and comfort with the status-quo does more harm than good in my opinion. I’ve seen that KDE.News seems to occasionally suffer the same thing though it thankfully doesn’t look as bad for them yet. It’s the dark side of the FLOSS community, I guess.

What do you do in your free time?

Doing things with my wife and two cute and funny little daughters, or working on Gnome.

Married, partner or up for adoption?

Married to Deborah (sorry, it doesn’t look like I have any pics online), the most loving, patient, understanding, and fun person I know. I don’t know why I was so lucky to end up with her but I am very happy about it. 🙂

If you have a partner or children, how do they cope with a GNOME addict?

I have no idea how they are able to manage, but they do so amazingly well. Luckily, they all love Gnome too. (Of course, the 1 and 3 year old haven’t seen anything else…)

If someone visits your country, which spot is a must-see?

I’m probably the wrong person to ask; I hate travelling. Vacations are times to relax, not to wear yourself out going somewhere to see something. When I went to D.C. for a conference last year, I went and saw some of the “big sites”—the National Museum of Natural History, the National Gallery of Art, the National Air and Space Museum, the Wasington Monument, and maybe others. Mind you, I “saw” them (from the sidewalk or across the street); I didn’t go inside them. I walked by them at a brisk pace, not because I had any interest in any of them, but merely because I knew lots of people would be asking me the following week what I saw while I was there, and was tired of thinking up excuses in previous years for why I didn’t waste my time doing so.


A phrase?

I saw this one added as a quip to some bugzilla and we’ve often used it as the topic in #bugs since: Quality Assurance—My value is based on finding fault in others.

A movie?

“What about Bob?”, simply the best movie of all time. 🙂

A book?

I’m not really an avid reader. Outside of technical stuff (things like scientific and mathematical books/manuals, programming guides/manuals, etc.), the only thing I read regularly is the scriptures.

A food?

Cereal. Mmmm…

A place?

Home, sweet home.

A text editor?

emacs, despite having horrendously ugly widgets and fonts and also lacking UTF8 support. I suggest gedit to others, though.

A band?

My CD collection might be in the double digits, but if so, just barely. If I had money to splurge on music, I’d probably buy some Manheim Steamroller CDs. But I don’t. When I listen to music, it tends to be classical, or perhaps what others put on (but then I won’t know the name of the band or the song or likely be able to decipher the lyrics).

A song?

Weird Al Yankovic’s “Spam”. As one of my friends once said, “Spam is just inherently funny” (no, not the kind that now affects our inboxes, this was said long before that was a problem)

Discuss this story with other readers on the GNOME forums.

Deskbar: A Bar For Your Desk!

With the release of GNOME 2.14, a new applet has been made available for the GNOME Panel: Deskbar. Deskbar is the all-in-one action bar, yet despite the name and its appearance, very few people actually know what it does, or how to use it. Davyd Madeley takes a closer look.

Deskbar is the brainchild of Nigel Tao, Raphael Slinckx and Mikkel Kamstrup. A salesperson would describe Deskbar to you as an omnipresent, versatile search interface. In short, it is a way for you to find what you want without your fingers ever leaving the keyboard. Those who have used an Apple Macintosh would describe it as similar to Quicksilver.

Getting Deskbar

Deskbar is already available packaged in Debian Unstable, Ubuntu Dapper, Ubuntu Breezy (in Universe as a Backport, or an older version), Fedora Core 4 & 5 Extras, Mandriva Cooker and more. You can also get the latest tarball from GNOME FTP server and compile it yourself.

Once installed, you can add Deskbar to your panel by right clicking on the Panel, selecting Add To Panel… and selecting Deskbar. Deskbar has two display modes: either as a bar directly on the panel, similar to how the Command Line applet worked; or hidden behind a button, useful for vertical panels and panels with limited space.

What Deskbar Can Do For You

Deskbar can be instantly accessed from anywhere by pressing the keyboard shortcut [Alt]+[F3] (you can change this in the preferences if you like). It will then match terms as you type, displaying a list of items that match your query.

Deskbar can match and load history (items you’ve entered before), installed programs, bookmarks, disk drives, shared network places, web addresses, email addresses, files, folders, smart bookmarks, Beagle, Google (live) and much more.

For example, if I press [Alt]+[F3] and enter ‘net’. Deskbar will match several items from my GNOME menu, as well as the bookmark ‘UCS Netusage’. If I ask for more details, it will offer to execute the command `net` or define “net” using GNOME’s builtin dictionary. If you’re using GNOME in a language other than English, you can also search in that language, as well as in English.

A little known feature, if you want to execute a command and see its output, execute it with the keyboard shortcut [Alt]+[t], instead of Enter. This will capture the output of the command into a window.

The preferences dialog allows you to choose which search plugins you want to include when searching. You can drag and drop them to change the order items appear in the search. Some plugins offer more settings, these are made available through the “More…” button down the bottom.

Extending Deskbar

What makes Deskbar cool is how extensible it is. Like Deskbar itself, Deskbar plugins are written in Python. Already, third party extensions exist to allow users to search the PyGTK API, control music players, do simple calculations, search GMail and access

To install a new Deskbar extension you only have to copy the file to your ~/.gnome2/deskbar-applet/handlers/ folder. Examples on extending Deskbar are given on the wiki.

Where We’re Going, There Are No Roads

The development of Deskbar did not stop with GNOME 2.14. Raphael Slinckx gave an overview of what he would like to see in Deskbar 2.16: bookmarkable search results, new extensions, an extension website you can download from directly, improve the speed of the Deskbar and of course, fix bugs. The Deskbar development team is gladly welcoming new ideas and new features, so feel free to connect to #deskbar and start contributing.

Discuss this story with other readers on the GNOME forums.

The Portland Project

The Portland Project recently gained attention by announcing plans to create an additional set of standards for Linux desktop environments such as GNOME and KDE. Sri Ramakrishna explains its aims, gleaned from a conversation with one of its lead architects, Waldo Bastian.

I had the opportunity to spend a little time with Waldo Bastian over a cup of coffee about the project he’s leading called “The Portland Project”. The Portland Project has recently been in the news thanks to an OSDL press release and coverage at major Internet sites. Waldo, in addition to being one of KDE’s major contributors, works with OSDL (Open Source Development Labs); an organisation that aims to bring Linux to the mainstream. Waldo is chair of the OSDL Desktop Linux (DTL) Technical Board.

Waldo’s introduction to the project actually starts with 10×10, Jeff Waugh’s rallying cry at GUADEC 2005 (GNOME User and Developer European Conference), a vision that Waldo agrees with and wants to see accomplished. The fundamental question Waldo asks is “How do we get there?” To acheive this goal Waldo believes that one of the things we need to look at is identifiable usage models.

Within OSDL DTL, five different categories are recognised:

  1. Fixed function. This means that people use the system for only one task. Typical examples are Point of Sale (POS) terminals, ATM machines and airline boarding pass kiosks. An increasing number of these systems are running Linux, but it isn’t very visible. Typically you only see the one application that is running on these types of installations. These systems don’t tend to use the “desktop” concept.
  2. Transactional workstation. Here people typically use one business application, and there may be some additional tasks that require sending e-mail or using a a web browser. This is the kind of system that you find in call centres, for example.
  3. Technical workstation. This is an interesting one because this is an area where traditionally Unix based work stations have been used. There has been a lot of migration from Unix based systems to Linux systems in this category over the last years. Many microprocessors are being designed on Linux based workstations these days, and if you were at last year’s GUADEC you would have heard how Dreamworks is using Linux workstations for its work on animated movies.
  4. Basic office. People in this category use office applications, e-mail and web browsers to access an intranet, or to access web-based applications. The amount of functionality used is rather limited and doesn’t change much over time.
  5. General purpose/advanced office. In this category people are using a wide variety of different applications and there is much more variety in the tasks over time. There is a lot of interaction with people in other organisations.

The other side of coin is the issue of application availability, which plays a role in corporate and enterprise as well as home users. Tellingly, Waldo thinks that the issue of application availability is not going to be solved with free software alone. This is because there are classes of applications that just don’t commend themselves well to the open source approach. For example, it’s not good enough to have TurboTax-like software if it isn’t updated in time to keep up with existing tax laws in the country and locality in which you live. Free and Open Source Software projects have historically been poor in positioning themselves to meet those deadlines due to the fact that they (usually) have only volunteer resources. Unless there is a company behind the project that is willing to keep tax software updated it’s unlikely that it will be accomplished successfully year after year (and well ahead of the filing deadline).

Waldo makes the argument that Linux needs to be able to address application availability and to support usage models like “advanced office” in order to make Linux a viable desktop alternative. Lack of such applications is a deterrent to acceptance (in addition to hardware support, in particular support for peripherals). We have frustrating situations where when you meet with hardware and software vendors they acknowledge that Linux is a great platform and they would love to support it but there are too few sales to justify investing a lot of money in it. A classic chicken and egg problem!

In order to break out of this situation we need to think about market share. We need to present Linux as a single unified platform, not as a diverse eco-system that forces ISVs to look at the various parts. Vendors should not have to deal with KDE or GNOME, but rather with the “Linux Desktop”. When we present Linux as a single platform we are creating a market segment for ISVs that is significant. When we show a large percentage of market share we have something to drive both hardware and software vendors to support Linux. We should fight fragmentation in Linux distributions and the desktop environments. Creating strong standards is a key strategy to encourage third party software investment.

I mentioned the fact that ISVs seem to have the most trouble with packaging since we don’t have a package format that transcends all distributions. Waldo acknowledges that standards in packaging are lacking and mentions that the Desktop Architects conference meeting in Frankfurt, Germany will be talking about issues like these. The idea is to make recommendations to distributions to improve their products, including packaging. LSB prescribes a packaging format in the form of a subset of the RPM format. So even though Debian, for example, uses a different packaging format natively, Debian supports installing these LSB-compliant RPM-based packages as well. There does seem to be quite a bit of room for improvement in this area though. So far packaging on Linux has been mostly approached from a Linux distribution point of view, and less so from the point of view of a software vendor who wants to distribute his software independent from a distribution, and for all kinds of different distributions.

Waldo shifts his focus to a problem all of us are familiar with. Which desktop should we develop for? ISVs have the perception that if they have to write an application, that they will need to choose between one desktop environment over the other. While there is a bit of truth to that, the reality is that 90% of the functionality an application requires comes from the X server. Only 5% of the desktop environment is Desktop Environment specific, but we have to deal with the 5% that is the difference between the desktops.

Good examples are starting an e-mail composer, opening a URL in a web browser or running an application as root. Both GNOME and KDE provide the same functionality; the difference is how you access that functionality.

Waldo asks “Can we define an interface that glosses over the differences and provide one interface, and let you access that functionality at one entry point?” This is the basis of the Portland Project: to provide a stable set of interfaces that ISVs can develop against and that will work under any desktop environment.

Waldo points out that Project Portland is not a widget set. There are plenty of widget sets out there and we have the ability to use theme engines to be able to make them all look the same visually. Differences like button ordering and dialog boxes can and will be addressed by being able to apply policy across all applications regardless of toolkit used. The point here is that the desktop environment can set a policy for that and the widget toolkit can follow that policy. GTK for example already has a gtk-alternative-button-order setting. Same for colours and fonts. It should be noted that fonts aren’t handled very well currently.

The Project Portland will provide the interface and also reference materials for developers. Application developers can use these interfaces to integrate well with both the KDE and GNOME runtime environments.

Linux developers will have the freedom to change how the interfaces are implemented in order to add more value to those interfaces. At the same time, the interfaces need to be stable so that they can be relied upon. Additionally, these interfaces can take advantage of other parts of Linux, like SELinux, allowing greater integration.

Linux desktop or distribution developers will have the freedom to change how the interfaces are implemented in order to add more value to those interfaces. For instance, if your application needs to use root access the current implementation will prompt for password and uses su, but you’re free to implement one for your platform based on sudo for example, or one that requires a fingerprint instead of a password. The Portland Project wants to give as much flexibility in how Linux developers implement the interfaces. The important part though is that the interfaces themselves remain stable, between different distributions as well as over time, so that application developers can rely on them.

Some issues that The Portland Project have been working on are default applications. ISV’s would like to have a way to register their application as the default application to handle file types they support. This feature can be open to abuse, as we’ve seen with Windows. But by directing applications to a single interface we can explicitly control that interface. We also need to be aware that we should handle future problems like malware and viruses. A lot of people still seem to think that as long as there is no root compromise there is no problem, but if your data is compromised or deleted it doesn’t matter whether your OS is protected!

We still need to be able to deal with these issues now before they become widespread. With existing security systems in place like SELinux we can integrate them at a single point and be able to assert control over it. When an application attempts to violate a security policy it will not have permission to do so. Waldo says that we need to think about these issues now before they become widespread. If we introduce well defined interfaces for applications to go through, we can put policies in place behind these interfaces. For example we can prompt the user and ask whether he or she really wants to use application FooBar to open all their *.doc files; or maybe we want to let the system administrator put rules in place for that.

The great thing is that with emerging new security systems such as SELinux and AppArmor we can actually enforce that applications go through such an interface and we can be sure that any policy is enforced: An arbitrary application would simply not be allowed by such security system to make changes to the GNOME or KDE configuration files that determine which applications are used by default.

Autostart is another vulnerability that needs to be addressed. Malware can abuse this feature by inserting itself into the login process. We need to start thinking about addressing these kind of problems. By defining interfaces that applications have to go through we introduce control points that we can use to contain these kinds of threats. There is of course a lot of work to do: in current systems there are many different ways malware can insert itself into the login process; autostart is just one of many.

The end state is that we move certain kinds of functionality out of individual toolkits and instead move them towards the Linux platform by encouraging ISVs to using a standard set of interfaces. By doing so we make room for all kinds of innovation across the Linux platform space, e.g. by GNOME or KDE or by Linux distributors.

As we finished our cups of coffee, and our conversation, I had some time to reflect on what Waldo was trying to tell the desktop community. We need to stop looking at our individual areas and see the Linux desktop as a whole. The idea of market share is a strategic way of getting ourselves out of the catch-22 we find ourselves with vendors and make real progress towards the Linux desktop as a dominant platform for ISVs.

The Project Portland is only one of several projects that work towards building the Linux platform. The other significant effort is the Desktop Architect meetings that seek to form standards in packaging, distributions and desktop technology. The Project Portland will work with popular desktop environments like GNOME and KDE to enhance it’s interfaces in order to support the needs of ISVs around the world.

I’d like to thank Waldo Bastian for taking the time to talk to the GNOME community about The Project Portland and his vision for the Linux platform.

Discuss this story with other readers on the GNOME forums.