Category Archives: April 2011
Cathy Malmrose of Linux hardware firm ZaReason asks the GNOME community to solve the two biggest pain points she sees.
I build hardware. I love using a little screwdriver to take off the panel on my laptop to look inside. I especially love the laptop that a developer at our shop has in R&D – a 17.3” screen 1920×1080 res (better than my 50” screen at home), a core i7 processor, 12 GB triple channel RAM, 3 hard drive bays, 2 video card slots which can have an ATI Radeon 6970 or an nVidia GTX 460M, 470M or 485M, then a bunch of USB ports and other cool things (like RAID 0, 1, or 5). Why that much power in a laptop? Because just the thought of it makes me giggle and I have seen more than a few hardcore developers laugh in a similar way then they consider having that much power in their backpacks.
We are doing what we can to build out a hardware line that is optimized for various free and open distros. We have plenty of work to do on our end, but when a developer or group of developers ask us, “What do you need?” we jump at the chance to let them know.
First – this will hopefully make some developers salivate – we would like to launch an open tablet. All we need is a context-sensitive on-screen keyboard, a few final tweaks, and we would be launching the first tablet that is released with its source code: the first non-iPad tablet to not violate copyright. Just having a non-violating machine available will put pressure on the dozens of companies that are launching Android tablets without the source code. There is currently a mass violation of the GPL by every Android tablet vendor who is not releasing the source code with the hardware. There are a few promises of releasing it later, but that is a bit like dousing someone with water then telling them you will get them a towel to dry off, maybe in a month or two. For the people reading this piece, people who like to improve the code base, it is unpleasant to not have access to the code.
Why can we not release the code? If we wanted to launch a tablet with Android we could have and would have last year. But with Android, since it contains some Apache licensed parts, the OEMs do not have to release it. We have brilliant staffers on board who could make a tablet work fine, but without passing the code along to you, fellow computer users, we are no better than any of the other greedy corporations out there. Even Google is now saying they won’t release the code for Android 3.0 any time soon, even though it used it on an already-shipping tablet.
We have strong and active connections with some of the best manufacturing plants. We have a tablet designed that is ultra-sturdy, has sleek, eye-catching design, day-long battery life, the full package, except for the most important part – the code. We do not need the code to do our work, but we do need to be able to provide it to you.
Why can’t we release a tablet with GNOME? The code is available, we could pass it on, and it would provide a much more solid and usable foundation. But we can not, because the context-sensitive on-screen keyboard is not available. We simply do not have the time to make such a significant contribution to the code base. We make our small contributions and send them upstream, but if we pursued this, even as tantalizing as it is, it would distract too heavily from our core focus – getting free and open source computers out to the people who need them.
We have spoken with several organizations that support the development of free and open software. And it appears that, as always, the final solution will come from the developers who are, as always, generously donating their time to implement and test new features.
Since we opened in 2007, we have had people asking us, “Will you ever launch a tablet? Please do a tablet?” We had a tablet ready in the summer of 2010 and would have launched it (allowing the iPad to make tablets popular) except for that one little detail – we must be able to pass the code along to you. Personally, I am motivated to get this done. A month ago Peter Mui of Fix-It Clinic fame gave our family a tablet he was not going to be using. I saw the way my children played with it and used it to do good things.
Second, we need simplicity. Bloat and feature creep can take down even the best projects. An ability to kill “the extras” for the sake of simplicity and ease-of-use rules in the end. How is GNOME faring in this regard?
Please listen into to a conversation I had with the ZaReason CTO, Earl Malmrose:
Cathy: “So, what do you think needs to be fixed? Most urgently? Think: GNOME community.”
Earl: “Hum. That’s a good one. How about the file overwrite dialog?” (pause) “Oh, they fixed that in the last release.”
Cathy: [same question]
Earl: [similar answer, but with a different feature]
As a hardware builder, it is sheer delight to see bug squashing at such a rapid rate that it is still logged in recent memory. And GNOME Shell is a big step in the right direction. But being geeky people, we never give up, do we?
We are taking Matt Asay’s advice to heart. In The Register he suggested that we: “strip out every last vestige of Linux’s old complexity; anything that might contribute to user confusion or system instability. Every menu item that doesn’t immediately make sense to a child. Dump it.” Personally, this resonates throughout how I live, how I build, and the type of system I need to build for people who are calling our little ZaReason shop.
We need simplicity more than most people realize. For example, a few days ago I was answering the phone in the early morning hours before other staffers arrived at work. I received a call from an elderly gentleman explaining how sick he was of his [proprietary OS] computer crashing. He was nearly in tears. He was tired, confused, and traumatized by the unexplainable and relentless crashes. He needed respite.
What do you say to a kind, soft-hearted man like that? “We are too busy obsessing over features to get you what you need?”
No, we say, and should continue to say, “We are aware that the current state of [proprietary OS] computing is a mess. As a GNOME community we are focused on simplicity. We are here to meet a deep and pervasive need. We are aware of our philanthropic impact and appreciate knowing that we can improve your quality of life. As we build GNOME by the generous efforts of a brilliantly intelligent volunteer community, we will continue to reject complexity and diversions so that we can meet our unified end goal – building a stable, highly usable OS.”
GNOME 3.0, with the GNOME Shell, simplifies the user interface so users can concentrate on the activities they care about. Perhaps GNOME will lead the lead the way both in a respectful-to-the-GPL tablet and in overall simplicity?
We wish the GNOME community could see and hear the people we talk to daily: the parents wanting a computer “that my son can’t load up with every virus he comes across while playing on armorgames”; the university students explaining, “I can’t afford the [proprietary software] upgrades and I heard that [FOSS] can do what I need?”; and especially the elderly people who “simply do not have time for blue screens.” People are asking for simplicity. If anyone in the FOSS world has the foundation to provide this, the GNOME community does.
Cathy Malmrose is CEO of ZaReason, Inc., a computer company aimed at setting up little self-sustaining shops internationally where people can see, touch, and play with sturdy optimized-for-FOSS computers. Her main goal is to “provide people with computers so solid that the person using them experiences a quantifiable improvement in quality of life.” She can be reached at email@example.com.
Sumana Harihareswara interviews Tomeu Vizoso and John “J5” Palmieri about PyGTK, GObject, introspection and PyGObject. What’s new, what’s been hard, and what’s next?
Sumana Harihareswara: It’s my perception that the PyGObject project is part of what’s exciting for developers about GNOME 3—under-the-hood improvements that give application developers more power and flexibility. Is that right?
Tomeu Vizoso: I think so. During the development of Sugar (which makes extensive use of Python, GNOME and Freedesktop), I have felt several times the limitations imposed by the unavailability of Python bindings and their lack of maintenance and packaging. There’s great work going onto the GNOME platform, and it was frustrating not being able to fully use it. And, as a nice side effect, with PyGObject we were able to address the terribly slow startup and memory usage of PyGtk applications.
John [J5] Palmieri: I would say that Introspection in general is very exciting. The idea that you can write a relatively small kernel of code to interface with any language runtime, and automatically get access to a large number of GObject-based libraries, means that the barriers to developing for GNOME are significantly dropped. The ability to move between Python and C fairly quickly means you can prototype in a scripting language and then write the slow bits in C for performance enhancements. And, as we have seen with the libpeas development, a library for creating a Python plugin frameworks in PyGObject Introspection, it makes providing extension points for your apps easy. Python has historically been the most popular GNOME scripting language, so it is logical for it to be the most complete at this point.
Python, C, Overrides, and the switch
SH: What misconceptions do you want to clear up about PyGTK or PyGObject?
TV: I would like to make it clearer that there’s no need any more for bindings for each library. You just need a recent PyGObject to be able to use GObject-based libraries from Python code. Though an introspection-enabled PyGObject is already stable and well-supported, it will take a while until everything works at 100%, so now is the moment for applications to be ported and bugs filed.
JP: I would ask this as, what are the differences between PyGTK and PyGObject, and why did we decide to use PyGObject over PyGTK for the future of GNOME?
It is first important to point out to the reader that PyGTK is actually based on top of PyGObject. At one point PyGTK was one monolithic code base. However, as gobject became useful outside of just building GUI applications, PyGTK lagged behind, requiring a dependency on GTK+ for apps that just wanted to use some of the non-GUI modules.
It was decided at one point to split the modules into PyGObject and PyGTK, where PyGTK would just be another static binding that was built on top of the PyGObject core.
During the 2010 Python Hackfest in Cambridge, Massachusetts, it was decided to continue work on PyGI, the Introspection fork of PyGObject, and eventually move it back into the PyGObject library. Again, PyGObject would be the base for other gobject-based libraries, except this time you wouldn’t have to write glue code to get them to work.
This is the major reason we decided to move to Introspection instead of continuing patching the static bindings. For instance, we were able to support GTK3 along with the new APIs such as gdbus and GtkApplication with minimal work. The great thing is, a lot of the code that went into making GTK+ work with Introspection benefits other gobject libraries as well. It also makes Python 3 support much easier to maintain, since all the Python 3 code is localized to the PyGObject code base. The modules that run on top of the main PyGObject code don’t have to worry about supporting C Python APIs. They only need to understand the base GObject Introspection concepts such as annotation and modelling API’s so that they are wrappable. This base understanding actually makes GObject developers write clearer public APIs by restricting the use of, or confining to private APIs, some of the more esoteric code patterns that C allows.
Unlike PyGTK, we also support overrides written in Python itself. The two uses of Python overrides are (1) to support legacy APIs such as a PyGTK compatibility layer, and (2) to make APIs more Pythonic by hiding some of the C’isms that direct API mapping exports. This has been a great motivator for getting people to contribute to the project. Since the barrier to contributing has been lowered by moving to a Python API from C Python API, any person who has ever wrote a PyGTK app can now write overrides with very little extra effort. We have seen a lot of contributors start with the Python overrides and then start diving into the actual core C bits.
That isn’t to say PyGObject Introspection is perfect. We still don’t support 100% compatibility in PyGTK and never will. Overrides come with some overhead and we prefer C authors to write APIs that are usable without them, bringing the advantages to other scripting languages as well. PyGTK will also be closer to the Python way of doing things, because it focuses on individual APIs more than the generic approach we take with Introspection, trading off maintainablitly for a kick-ass interface. There is also the dependency issue, which isn’t fully worked out yet. PyGObject’s dependencies are soft dependencies, so there can be issues if C library APIs changes aren’t caught before they are deployed. With PyGTK, there are hard compile time dependencies, so packagers are alerted early in the process if they are updating a package that may break things. PyGTK has also been rock solid for ages now. It will be awhile for critical path PyGTK apps, such as Fedora’s Anaconda installer, to fully trust the new way of doing things.
Sponsors, contributors, and upstream/downstream
SH: What companies and organizations have been sponsoring this work?
TV: I started my work on PyGObject as part of my involvement in Sugar Labs, and when I was later employed by Collabora, they sponsored this work. It has been critical as well to get the support from Red Hat by putting J5 full-time to work on this. Lately Martin Pitt from Canonical joined the team, and has been doing a really awesome work while porting his apps to introspection.
JP: Collabora has been great with providing us with funding for hackfests and giving Tomeu the time to hack on major parts of PyGObject. I also can’t thank Red Hat enough for allowing me to work full time leading the project (even though I probably should be working on more Fedora’y type projects). Martin Pitt was also at the last hackfest representing Canonical. He is responsible for making the GDBus overrides easy to use. However, to a large extent our developers are independent contributors from the community who started by submitting patches or bug reports and then slowly started diving into the internals. We welcome anyone who is interested in contributing. Come join us on #python at the GIMPNet IRC servers.
SH: …and who would you like to see step up and offer more support?
TV: I’m quite happy at the current support from both companies and volunteers alike (the GEdit/libpeas hackers have been great) but I must say that I have been quite disappointed at the big efforts that I have had to do to get downstreams involved. I believe it should be obvious that upstreams having to reach downstreams is not scalable: it should be the other way around. If you package software that is being obsoleted, you need to make some effort to understand what is the replacement. If you develop on top of some software, you need to understand where upstream is going and participate on its development. Money enters into the free software ecosystem through downstreams, and we need to get much better at channelling it to where it can have the most impact.
SH: The current porting status/TODO page shows that a lot of apps haven’t been ported yet. What do you expect the timeline will be for that? Is this an activity that we should have a hackfest for?
TV: From talking with application maintainers, they seem to have been waiting for PyGObject to be ready, as if it could have ever matured without their involvement. Fortunately, as part of the push for GNOME 3, a few have gotten involved and made it possible. But it could have happened way earlier…
I’m pretty sure a hackfest would be great for that, based on the outcome of the last one we had.
JP: There isn’t really a timeline. We started on this focus during the last hackfest in Prague, Czech Republic, except we were focusing on what porting applications needed fixed rather than actually porting applications (though that did happen at the hackfest). At Red Hat, we have a push to port modules to Python 3, so internally this will push a lot of our Python tools to move to PyGObject as well. In this next cycle I am concentrating on finishing my invoke path rewrite, which will simplify the codebase, speed up the core, and allow us to support some of the harder introspection use cases. Other than that, we should be focusing on documentation and porting. It is at least my hope that by the next major GNOME release, all of the most-used GNOME Python apps are either fully ported or on their way to be ported. The next hackfest should be 100% dedicated to this effort.
SH: What unexpected challenges or opportunities have you run across while working on this project?
TV: It was a challenge to pick up a piece of software that, though it was widely used, had been practically unmaintained for a long time. Part of what it made it difficult was that most users of PyGObject are reticent to read and write C code, unlike users of the C APIs.
It has been a revelation how hackfests can help bring new people to a project, mainly by helping stabilize personal relationships between old-timers and newcomers. After the last hackfest, I’m certain I won’t be missed in the project when I move to other stuff.
JP: The biggest challenge has been coordinating with the different libraries and applications which support or are supported by PyGObject. Introspection is very new and with that comes growing pains. Before the binding developers could work in a bubble, catching up to whatever the API developers added or changed however they saw best. However, now everything is so highly integrated that the binding developers have to closely work with the API developers. This can cause a lot of frustration and a bit of extra work for all involved, but in the long run the closer collaboration will reveal itself in a better end user experience. If we have learned anything in GNOME over the years, it is the end user that matters and using Introspection helps move towards that goal.
Sumana Harihareswara manages projects and people. She has worked for the GNOME Foundation, the Wikimedia Foundation, and Collabora, and contributed to the AltLaw,Empathy, Miro, and Zeitgeist open source projects. She is currently an editor and the release organizer for GNOME Journal and a blogger at GeekFeminism. She blogs atCogito, Ergo Sumana and microblogs at Identi.ca.
Daf Harries continues his interview with Jon McCann and Jakub Steiner. Should we be treating code and design contributions the same, or differently? What pitfalls from GNOME 2 were designers trying to avoid? How do we deal with community indecisiveness?
(continued from Part I)
DH: What are some of the pitfalls you think GNOME 2 ran into? What are some of the things we did well?
JM: I think the people involved in the early days of GNOME 2 were very successful at instilling a design culture into the project. Nicely complemented by a strong get-things-done ethic. Many of us were attracted to GNOME because we identified with it, we demanded better, and we wanted to demonstrate that we could be better.
One of the problems in GNOME 2 was figuring out how to make decisions. The technology world’s magnetic poles starting changing on us, and the initial 2002 compass wasn’t helping us steer after a while. This led to lots of disagreement and ultimately to a kind of fatigue. We started making design decisions through a module acceptance process that rarely had anything to do with project vision or design. It was seen as fairness but unfortunately that isn’t the same as greatness. We became a little too milquetoast, tolerant, and accommodating. People started to realize that this mediocrity wasn’t what any of us really wanted, and started agitating for a shake up. Which eventually led to GNOME 3.
JS: I saw even GNOME hackers using add-on tools to help them do the basic tasks GNOME was supposed to do. To me, projects like gnome-do or docky did a far better job at launching and switching between apps and documents.
And to me, the upstream visuals weren’t convincing enough for distributions to build on top of it with their branding, rather that creating their own thing completely. GNOME 2 got really fragmented. There was no unified feel to it. GNOME was always a very striving community, but I don’t think people felt like it was a product.
DH: Do you think we’ve gotten past that indecisiveness? How did we get better? There was some skepticism in the community when the GNOME 3 process began, but we managed to build consensus that it was a good way forward.
JM: I think time will tell. I expect there will always be indecision, debate, and discussion. There is an element of human nature there. However, I think it is important for us to at least agree on some basic things. Without that, rifts form and can destroy a community. You really need to agree on your brand. That is: a) who you are; b) what you are doing; c) why it matters. I think once you reach a rough consensus on that, the rest flows. We’re clearly still working on it.
DH: Clearly there won’t be a GNOME 4 in the near future, but what are the things you would do differently in future projects?
JM: I think that once GNOME 3 is out the door we’ll have a chance to look back and second guess the process we used to get there, but for now I feel great about what we’ve managed to accomplish. We’re doing something that nearly everyone said we couldn’t do. Creating innovative, elegant, and coherent design in the open. Creating an operating system that we can be proud of. Creating a platform for participation in the future that we can share with anyone (not just the technical elite). I feel really good about that.
JS: Right now I’m just looking forward to tie up the loose ends and get GNOME 3 out the door. We have received some positive feedback so far but it will be interesting to see what the rest of the world has to say.
DH: There is a lot of experience in the free software community in organizing decision making and contributions around code, but we’re relatively inexperienced when it comes to design. Do you think code and design contributions can work in the same way, or do they need to be treated differently?
JM: A little of both, actually. I think there is something really amazing about the way a good open source project is maintained. A good maintainer, like any good leader, is responsible for making final decisions, accountable for those decisions and the decisions made by others in the project, consults with people in the project and people in the field, and keeps everyone informed of the project’s progress. This model has proven very successful with code. I think it applies equally well to design.
In GNOME Shell, for example, Owen is the maintainer and a very good one. He has delegated some of his duties in matters of design to me. I in turn delegate as much of that as I can 🙂 Owen reserves the right to make executive decisions but only exercises it in rare occasions in order to maintain a healthy mutual trust relationship.
Where things differ quite a bit between code and design maintenance is in how contributions are handled. Code contributions usually take the form of problem reports (bugs) and/or suggested code changes (patches). These are usually pretty easy for the project developers to evaluate, based on the known sensibilities and tastes of the code maintainer. There is usually some value of correctness involved that is rather apparent and involve small deltas to the current project baseline. This is less the case with design contributions. For sure, there are simple design bugs and even sometimes patches, but just as likely, if not more likely, are contributions of an entirely different vision. That would be equivalent to sending a code patch that refactored and replaced the entire project. That isn’t something that a maintainer can really do much with and so it turns out to be not that valuable.
Another difference, which has been covered elsewhere in great detail, is the effect known as bikeshedding, where the more superficial the issue, the more fierce the discussion. This seems to occur less frequently in code contributions. But it does occur. Tabs versus spaces anyone?
JS: For graphic design it is absolutely a case of everyone feeling competent to add to a discussion, even if the first thing they do is mention “Well I have the graphic skills of a 4 year old, but…”.
DH: Does that mean you do think there needs to be a different approach for graphics contributions?
JS: Probably not, it’s just that the ratio of useful feedback to noise is probably even lower than in technical discussions. People who actually do contribute artwork are usually willing to iterate and investigate a different path.
DH: Do you think that good design stems from a clarity and unity of vision? If so, how can we reconcile this with wanting to keep our projects non-hierarchical and open to contributions?
JS: The project lacking a vision is clearly not getting us anywhere. You don’t want to get people involved with the preemptive promise of including the design of a particular bit. The primary focus needs to be a good product rather than growing a fellowship. Sure it is necessary to investigate many options, but it’s just as necessary to kill off most of them. That process becomes close to impossible without a vision.
JM: As I mentioned earlier, I don’t think the clarity and detail of vision is always that important. You can be too certain of things and get trapped. You need to have room to wiggle, to play, to dance and be creative. But you need a structure and a direction too or else you’re just careering.
Being open to contributions is not opposed in any way to having good leadership and being able to make difficult decisions. You need both. You can’t evaluate contributions without the ability to decide. You won’t invite contributions if you show an inability to choose among them. You need to be able to communicate to the world: “Here’s where we want to go. Won’t you meet us there?” If you can do that effectively you’ll have the right kind of contributions and be even more open and transparent than before – with less discord and more harmony. And that’s the type of world we want to help create.
Daf Harries is a GNOME developer.
Daf Harries asks Jon McCann and Jakub Steiner: what was the seed that got GNOME 3 going? How does modularity cause problems? And how do new contributors learn a project’s design philosophy?
Editor’s note: Another brief history of GNOME 3’s design process, incorporating some quotes from this interview, is at http://live.gnome.org/ThreePointZero/DesignHistory.
Daf Harries: To start us off, tell us about your history with GNOME and your role in GNOME 3.
Jon McCann: I’ve been quite actively involved in GNOME for about 8 years or so. I was attracted by the design ideology of the project but ran into lots of issues with it in practice. I quickly learned that the most effective way to improve the design was to fix it yourself. I’ve been passionately working to improve the GNOME user experience ever since, by whatever means I can.
For the last few years, I’ve been coordinating the design of GNOME 3, leading the design for GNOME Shell and System Settings, and occasionally jumping in the trenches to help out with some projects. Oh, and trying to stay out of the way and let our talented visual designers and artists do their thing.
Jakub Steiner: I started working on GNOME as an icon designer after being involved with the GIMP project about 10 years ago. My focus has shifted to general visual design over the years, working on downstream projects, such as Ximian Desktop, building on top of GNOME, while contributing to upstream as well.
I had a bit of a hiatus from GNOME and felt like focusing on GNOME 3 visual aspect again. So while I am an old fart when it comes to GNOME, I got involved with GNOME 3 fairly late.
DH: Can you sum up the GNOME 3 design in a single sentence?
JM: Ineffable. Sorry, partly joking. We’ve taken a pretty different approach in the GNOME 3 design that focuses on the desired experience and lets the interface design follow from that. So, it is much harder to describe to someone than it is to let them experience it themselves. With any luck you will feel more focused, aware, effective, capable, respected, delighted, and at ease.
JS: GNOME 3 tries to get out of your way. We didn’t design GNOME 3 for you to discover. You should just be able to get your stuff done.
DH: When work started on GNOME 3, was there a conscious adoption of a design process, or have things been more ad-hoc? For the Shell, I’ve noticed that there was an explicit design document, which as far as I know is not something that happened much during GNOME 2 development.
JM: GNOME 3 was conceived at the GNOME UX Hackfest of October 2008 here in Boston. I think it is noteworthy that even before any kind of process emerged there was an intentional design-first ethic to the project. That was rather uncommon in open source at that time. I think we’ve gradually influenced a culture shift in the community so that it would be considered unacceptable to start a project in GNOME today without a design-first approach.
Perhaps the most notable part of the design process is that everything has been done in the open. We’ve had full transparency for every decision (good and bad) and every change we’ve made. We strongly believe in this model. It is not only right in principle; it is just the best way in the long run to build great software sustainably in a large community. We’re building a wave of change as much as we are building a series of great products. We’ve seen over and over how talented teams of designers have worked to build excellent products in silos but failed to sustain them or to effect meaningful change in the community. As I said, the GNOME 3 design started with a collaboration at the UX Hackfest that spanned the breadth of our community. We’ve always worked very hard to keep it that way. Unfortunately, we’ve hit roadblocks in some places. But we have never stopped reaching out to those folks and still welcome participation in the GNOME process. We understand that it is challenging to work in the open like we do. Many designers are not accustomed to it. You need to have a lot of humility to be able to show works in progress and have an extremely thick skin. People get to see the guts of the process and need to use some imagination to see where things are headed. You also need to prepare your ego for sharing credit or receiving none at all apart from personal satisfaction in the end product. Not all parties are prepared for that, as it turns out. You also have to accept that the entire world can monitor, critique, and learn from your progress while you have no access to or insight into their work done in secret. But those are just the rules of the game. If you want to take part you have to come out and play.
That design document started as my personal notes and things that I had been playing with for quite a while. It was helpful for me to try to organize those thoughts and try ensure they where self consistent and coherent. A design, especially an operating system, really needs to have this consistency. After a while, we realized that it would be useful to share this information online so everyone can see where I think we may be going. That turned out to be pretty powerful I think. One of the biggest challenges in open source design is trying to get folks thinking about and working towards a similar vision. You can’t really organize a community without such a guide. On the other hand, the vision needs to be blurry enough that you don’t get locked in too early and allow others to surprise you or help you refine things. Old-school, detailed specification manuals don’t really allow for that. But I think this pamphlet did OK. And we’ve been fortunate enough to have a lot of talented new contributors show up and keep surprising us. A good example of this is someone like Allan Day. He’s jumped in, engaged the project, built trust with developers and designers, and made a significant impact in a relatively short amount of time.
After a while we more or less stopped using the document because most of us had internalized it and it was time to move to higher order refinements or, in some cases where things just didn’t work as expected, complete revisions. We also transitioned to using wiki pages for most of our work since that allowed for more fluidity and easier collaboration.
That collaborative work was done primarily through online chat (IRC) with the love and help of the GNOME design community, who are not only very talented designers but folks that understand that designing such a complex system requires a very unique blend of holistic and specific thinking. It is pretty hard to do and really hard to do well. Like most good design it requires a commitment. It is birth, not death. Death is quick – like a drive-by shooting or firing off an email. But rearing requires nurture, understanding, empathy, and care. And we’re really lucky to have this kind of support in our community.
JS: I wasn’t there when GNOME 3 was conceived, I was in fact freaking out as a dad during that time. But I got hooked to work on GNOME again during the UX hackfest in London early last year. Of course it was a specific event where there probably was more designers than engineers, but the mood was very unlike my typical FOSS involvement where I’m only asked to use lipstick on a pig at the last moment. Before that I experienced something similar in the GIMP project. Peter Sikking has been asked and agreed to do some excellent design work there. It has been very welcome by the GIMP engineers and some really hot improvements came out of that cooperation for 2.6 and the upcoming 2.8. Both GIMP and GNOME 2 weren’t really designed before, it was very ad hoc.
DH: What was the seed that got GNOME 3 going? Did you come into the 2008 UX Hackfest with some existing design work? Were there a lot of competing ideas from the start, or did you quickly settle on one design?
JM: The desire to create GNOME 3 had been growing in the community for years before a few people finally decided it was time for some action and organized the 2008 UX Hackfest. We learned a lot in the process of creating GNOME 2. We watched the technology landscape change around us. I think, collectively, we were ready for a change. One notable seed was planted as far back as 2005 when Jeff Waugh was promoting Project ToPaZ as a way of exploring 3.0 design ideas. So, it was in the back of our minds for a while.
Consequently, I think most people at the hackfest brought design ideas with them. What was truly remarkable, however, was how much agreement we found. At least in the working group that I took part in, there was a camaraderie and genuine enthusiasm for finding a path forward. After spending a few days doing research, identifying goals and constraints, and generating ideas, we pretty quickly converged on a single rough outline. We spent the rest of the time iterating and refining it, mocking it up, and documenting it on the wiki. Personally, I came away from the experience incredibly energized and optimistic about the future of GNOME. Not only because I felt good about the quality of the results but that we demonstrated we could come together and work as a team. In this case, cooperation was much more fruitful than competition.
DH: You went to the trouble of distilling the design values you wanted for the Shell. How do you go about inculcating those ideas in new contributors? Does it happen via a sort of osmosis, or are things more explicit? Do you think it’s ever useful to keep the design document around, or is it something to write up before you start and leave behind once you’ve got going? And how does the HIG fit in with all of this?
JM: The beauty of it is that you don’t have to convince new contributors of anything. Most often they find you because they identify in some way with your vision or goals. In the best cases you find a kind of harmonic resonance. I am pretty convinced that the most practical way to build a community or a product is through such shared goals. To me, it is the critical difference between a discussion and a fight. You can have a discussion if you presume you are working together – in harmony. If you have fundamentally different ideas about who you are or what you are doing then you are discordant and bound to fight. And no one wins a fight.
I think, after a while, core values and core goals become part of the blood of a community and don’t really need to be held as doctrine. However, I’ve found that it can still be quite useful to consult them when trying to resolve design challenges. For example, our goal of “respecting the user’s focus” has informed a lot of the decisions we’ve made. And that helps keep our design focused.
The GNOME Human Interface Guidelines is primarily for application authors. So, it didn’t play that much of a role in how we designed the OS part of the user experience.
DH: To what degree is the GNOME 3 design the Shell design?
JM: The overall design has always been for the user experience of an operating system. We’ve never really considered GNOME 3 to be separate from the Shell. They are part of the same larger design and not separable components.
One of the things we we set out of fix in GNOME 3 was the over-modularization of GNOME 2. GNOME 2 had become a bit of a Frankenstein’s monster, assembled from bits and pieces that were not always designed to integrate perfectly. You could see the seams. And more importantly, you could feel them and they didn’t feel nice. So, perhaps the most important goal of GNOME 3 is this unification of the experience. When something does not draw attention to itself by revealing its construction it can comfortably recede into the background and become transparent to you. That’s what we’re after.
JS: I’ll only expand on that. Even if GNOME consists of multiple projects with small subcommunities, being involved and proud of their little darling, the focus is on the whole experience. A small component could actually be useful outside of GNOME, but that is not the focus. The UI can become much more streamlined if there is that one particular integration in mind.
DH: Can you give some examples of times when modularity caused problems? And of the kind of integration you’re aiming for?
JM: We began to realize there were very definite costs of modularity. There is a common misconception that modularity and choice within a system increases robustness and flexibility. In actuality, the at-arms-length standardization inherent in that practice dramatically reduces flexibilty in design and implementation, yields no benefit to people using the resulting system, and tragically reduces the overall quality of the product and brand. And as we saw in many cases in GNOME 2 it made certain problems intractable.
One example, is that in GNOME 3.0, for the first time in the history of GNOME (believe it or not), we have been able to integrate network management, user account management, printer management, and system time and date functionality. The only way we were able to effectively tackle these problems is by making very specific choices about what the user should see and building the technology as needed. It is theoretically possible to go through a standardization process to build modular components to implement those user experience goals, but in many cases the costs involved are prohibitive.
Another prime example is found in the implementation choices Owen Taylor made for GNOME Shell. In GNOME 2, the operating system shell was assembled from a variety of different components: a panel, panel applets, a window manager, file manager, various daemons that provided system control through so-called status icons, and so on. Each of these components existed independently and, while we did our best to make them work cooperatively, each behaved slightly differently and we never achieved the kind of coherence that we wanted. Owen made what I consider a very smart choice: to build the shell as a single entity. All of the parts designed to work together seamlessly as part of a single scene graph and with well-understood and deterministic interactions.
A final example, where a slightly different manifestation of modularity caused problems, is regarding the use of internal optional dependencies. Many of these options in isolation seem harmless on the surface, but in aggregate what results is a matrix of internal forks. The system may be built in any number of different ways. Each component must be designed to cope with all of those conditions. In many cases, the result was that the software could only rely on the intersection of those options – the lowest common denominator, if you will. In my opinion, that is the tail wagging the dog. Our first concern really should be what the user sees – the one thing we call GNOME 3.
By the way, I highly recommend checking out The Innovator’s Solution by Clayton Christensen for a very interesting analysis of the costs of modularization.
DH: How do you go about coordinating design over the whole project where maintainership is divided across modules? Have there been cases when it’s been difficult to convince a module maintainer of your global approach?
JM: It can be extremely challenging. I’m not sure we know the best way yet. What I’ve tried to do is continue to articulate the vision, build relationships and trust with maintainers, and communicate with as many people as I can. Of course, it always helps to have patches. And if none of that works – I beg and plead.
Sure, sometimes that isn’t enough. However, in the majority of cases maintainers were happy that we could actually more precisely define how the parts should fit together into a whole. In some cases this was because it made the code much easier to maintain. But more often it was because they really cared about the user experience.
(continued in Part II…)
Editor-in-Chief Paul Cutler celebrates GNOME 3.0’s release, and discusses innovation, pain, and history.
In just a few hours, on Wednesday, April 6th, 2011, our Release Team will pull the switch and release GNOME 3.0. It’s been a long time since GNOME has had a major release – this June will mark nine years since we shipped GNOME 2.0! Over those nine years, GNOME has consistently released a new desktop with innovative new features every six months. Thousands of developers have worked over the years to create a desktop, applications, write documentation and translate GNOME into over a hundred languages. And users, distributors, and vendors have benefited incalculably.
With GNOME 3.0, the GNOME Desktop takes a step forward.
And it’s a timely one, and a big one. People are not using their computers the same way they were nine years ago, when we released GNOME 2.0. The internet has helped change how we use our computer, computer hardware has become faster, and we expect different things today from our computing experience than we did then. GNOME 3.0 takes a step forward in thinking about, and addressing, all these things. Our designers created GNOME Shell to help reduce distractions and let you use your computer how you want to. Mark yourself busy and popups from social media, instant messaging or email notifications will be minimized until you’re ready to look at them. Find the applications you want to use faster, and get an overview of what applications are open with the touch of a button. Daf Harries interviews designers Jon McCann and Jakub Steiner in this edition, and they discuss how these design changes came to be in GNOME 3.0.
And this is only the beginning. GNOME helped pioneer the six-month development and release cycle in free software projects, and that will continue. We’ll continue to work on core innovations, changes and improvements to the GNOME Desktop and release them twice a year. After this revolutionary change will come the evolutionary ones. Cathy Malmrose’s article in this issue points to some pain points that the developer community will need to fix in the years to come.
We understand that change can be hard and not every user is ready to change their desktop experience from GNOME 2.x to GNOME 3.0. But if you look back at the changes that came in GNOME 2.2, GNOME 2.4 and so on, the desktop continually became better, and that will continue with GNOME 3.2 and each release every six months. The new platform enables greater functionality, more opportunities for developers, and easier extension than GNOME 2.x ever could have. Sri Ramkrishna’s article on extending GNOME 3 in a future edition of the GNOME Journal will touch on this and more.
GNOME is more than just a desktop. The GNOME Development Platform is a set of applications and tools, such as GTK+, that help developers and companies build applications and user interfaces on multiple platforms, including Linux, Windows, and Mac OS X. Users might not consciously notice improvements in the platform, but they’ll enjoy the benefits. Nicolas Spalinger’s overview of recent font improvements in this issue talks about Cantarell, the new default font, and covers all the behind-the-scenes work that will help make GNOME developers’ work look better.
GNOME’s technologies help power other products, including MeeGo, Sugar and One Laptop Per Child, and Unity. In this issue, Sumana Harihareswara talks to Tomeu Vizoso and John Palmieri about the improvements in PyGObject that helps developers use Python in GNOME—just one of many languages available within the GNOME development platform.
The GNOME Journal team is proud to bring you a special issue about GNOME 3.0. This is an important time in GNOME, and we hope these articles give you a broader look into the GNOME community at the time of this historic release.
Try out GNOME 3 – we think you’ll like it.
Nicolas Spalinger explains why Cantarell is more than just a font—it’s a symbol of a whole new design process. And he shows you how to tweak the font settings in GNOME 3.
What font-related goodies we can look forward to in GNOME3? In short, the GNOME desktop will use Cantarell by default. It’s an original contemporary humanist sans serif open font by Dave Crossland, designed to work well on-screen. GNOME will maintain and extend Cantarell as a official module. The font configuration options have been tremendously simplified in GNOME 3, but there are alternate tools and tricks to tweak them to your heart’s content. But how did we get here?
Fonts and related software before GNOME3
If we take a quick look at the history of fonts-related libre software, we can see that many maintainers of key components like Pango, Fontconfig, Freetype, Fribidi, Cairo, ICU (International Components for Unicode) and Graphite have been either affiliated with GNOME, in touch with the community online or in person at GNOME events. Over the years, the GNOME community has significantly helped the various pieces of the puzzle come together and encouraged incremental progress across development cycles.
Even better, back in 2004, realizing the needs in that area and unwilling to depend on restricted fonts any longer, GNOME made the bold move to commission the Vera font family from Bitstream, a US-based foundry. Building upon that major milestone, the work focused on more advanced aspects of font rendering. As a result, GTK+ and the corresponding capabilities of GNOME applications have grown even further to improve complex scripts support both for screen and print. Major GNOME contributors like Owen Taylor, Behdad Esfahbod, Keith Packard, Simos Xenitellis, Wouter Bolsterlee, Dennis Jacquerye and others played a significant role in making fonts relevant on the GNOME desktop.
The conundrum of subpixel rendering, hinting, anti-aliasing options and the big matrix of choices was exposed in the GNOME control center and refined over many GNOME development cycles.
We had various incarnations of small utilities to browse, compare or manage fonts; gnome-font-viewer (thumbnailer and viewer, now with a simple installation feature) has moved on from the original fontilus suite by James Henstridge to be part of gnome-utils. Font tools like gnome-specimen by Wouter Bolsterlee or font-manager by Jerry Casiano cater to the needs of more advanced users.
More recently, the design and API integration discussions have led to the creation of Harfbuzz . You can find a fairly good overview – if not fully current – of the progress in Behdad Esfahbod’s State of text rendering. Representatives from QT, KDE, W3C, Mozilla, OpenOffice.org and SIL have actively contributed to these discussions and to the code. With the release of GNOME3, this work becomes more apparent and points to promising avenues for the future.
The rise of LGM (Libre Graphics Meeting) and the focus on UX (User eXperience)
Since 2006, the LGM has been a key event for movers and shakers across the wider community with interest and expertise in the area of graphics. Every year was a tremendous opportunity to explore new ideas, learn from others, discuss plans, implement changes and move forward on many graphics-related challenges, including fonts. Every LGM has seen an increase in the number of talks, presentations or workshops focusing on font-related topics, with the presence of font experts from various FLOSS communities. One good example is the complicated and multi-faceted topic of webfonts: it’s no exaggeration to say that discussions and networking opportunities at LGM had very significant impact on the current webfonts paradigm shift.
GNOME contributors have been active with LGM over the years, as well as participants in the TextLayout Summits which co-located with LGM a few times. Further discussion and conference calls within the loose umbrella of freedesktop.org and the wider open font community have allowed us to bring together low-level library maintainers, designers, and developers, with a focus on internationalization (“i18n”) and fonts-related issues.
The greater – and much needed – focus given to usability and interaction design we have seen over the past few years has fueled efforts around increased availability of quality open fonts, expanding both artistic choice and support for the diverse communities using GNOME in their own language. From only a handful at first, we now have a few hundred open fonts available. Many designers have seen the value of releasing their projects under a FSF/OSI-approved and community-recommended font-specific license, like the Open Font License, and various for-profit and non-profit entities have supported the work on unrestricted fonts for the wider benefit of all, including users of the GNOME desktop.
We now value recognizable typographic look and feel as a differentiating aspect of a project. Various prominent projects, like Ubuntu, openSUSE and Fedora, have decided to use an open font in the fabric of their visual identity. They do this so that their brand is more in tune with their values, and derivative localized community marketing material can be more easily created within the appropriate trademark boundaries. Having quality open fonts used to be an afterthought, but we now recognize it as a key part of the UX: much more than the fundamental building blocks of literacy and knowledge, they are also art and beauty, and have a huge role to play in the subtle difference between engaging and painful to use.
Cantarell: moving beyond commissioning
After last year’s Boston summit, the GNOME designers announced their choice of a new default open font in gnome-shell. GNOME was the first major community project to commission an open font, and now they are innovating again by selecting Dave Crossland’s original Cantarell (designed as part of his studies at the prestigious Reading Typography Department in the UK) – to become part of GNOME, to live and grow in cadence with the GNOME release cycles.
Font designers, much like other software authors, enjoy picking clever names with deeper meaning. So I’d recommend you ask your preferred search engine about the meaning behind this particular name. It may well make you think!
The commissioning approach to fonts involves a proprietary foundry developing a font family in-house, and then transferring it to a community who will maintain it with a different toolkit and methodology. A fully libre software project approach, in contrast, develops fonts with a FLOSS toolkit on a FLOSS desktop from the start, and hosts and maintains them like other modules in the community’s infrastructure. (In GNOME’s case, those comparable modules would include git, Bugzilla, the wiki, etc.) GNOME is blazing a brand new trail in moving from the commissioning approach towards a libre approach.
Jakub “Jimmac” Steiner, designer extraordinaire and core LGM contributor from the earlier days, now also committer to Dave Crossland’s project, had already designed open fonts of his own. He indicated in his blog that the methodology used by Dave Crossland was more in tune with GNOME’s culture and made much more sense in the long-term. They are many challenges ahead but these are interesting times.
Personally, it makes me happy to see that a font released under the licensing model I’ve worked on for years, with tremendous input and support from the community (see the Go for OFL community campaign ), has now also been chosen by GNOME to enable software freedom, explicit embedding and bundling permissions, while retaining copyleft and offering dedicated collaborative mechanisms in tune with the specific way font designers and script engineers work.
But let’s not forget that DejaVu, the major branch of the original Bitstream Vera, has been quite successful and is very widely used. The core maintainers, Dennis Jacquerye and Ben Laenen, and many many contributors do a lot more than maintaining what the original foundry shipped. They have actively consolidated many branches, introduced unique features and validated best practices which have pushed many software projects forward. But the full font sources, design guide and post-processing tools from the original foundry – although promised repeatedly – sadly never surfaced. Giving prominence to Cantarell in the UI will not make the amazing work done with DejaVu over the years disappear. Nor what the Liberation maintainers have achieved. Different scopes and different origins call for different approaches but they can be mutually beneficial.
Tweaking your fonts in GNOME 3
Even if GNOME 3 designers have chosen to considerably simplify (to put it mildly) the various GUI parameters available to tweak your fonts to maintain consistency and a recognizable look and feel, you can still tweak fonts to your liking under the hood.
The current version of Cantarell, although it will surely expand in the future, does not cover all the range of supported languages of GNOME. In practice, you will get fallback from other fonts shipped by your distribution to complement the current offerings of Cantarell.
Depending on your needs, you can tweak fontconfig settings, including priority ordering and the Sans/Sans-serif/Monospace generic families. Besides editing the fontconfig configuration in your preferred text editor directly, you can use Fontik to override system-wide font settings.
You can also use the gnome-tweak-tool add-on to adjust certain font features directly impacting the behavior of your new desktop.
GNOME has moved to point sizes instead of pixel sizes (pt instead of px in the CSS) to consider flexible scale factors available in high-resolution screens. You can manually adjust the sizes in /usr/share/gnome-shell/theme/gnome-shell.css .
Using dconf-editor or gsettings you can explore and change the appropriate configuration settings:
gsettings list-keys org.gnome.desktop.interface.*
gsettings set org.gnome.desktop.interface.foo "bar" "7"
For a variety of reasons beside coverage issues, you may prefer using an alternate font. Using gsettings you can change the default font. For example:
gsettings set org.gnome.desktop.interface font-name "Dejavu Serif 10"
gsettings set org.gnome.desktop.interface font-name "Liberation Serif 10"
gsettings set org.gnome.desktop.interface font-name "Linux Biolinum G 10"
You can also tweak extra font settings. For example:
gsettings set org.gnome.desktop.interface monospace-font-name "Inconsolata 10"
gsettings set org.gnome.desktop.interface document-font-name "Andika Basic 10"
settings set org.gnome.desktop.interface text-scaling-factor "1.1"
Your preferred distro should already ship with a good selection of open fonts in a default install, with plenty more available from the repositories or from online open font catalogs.
Looking into the future
Balancing the tension between maintaining a unique visual identity and expanding linguistic coverage for the diverse GNOME community is an exciting challenge to tackle. But the tools and infrastructure are now in place: the open font design toolkit is maturing, and with designers’ voices being heard, fonts will take on bigger roles. With the innovation happening around webfonts and similar technologies in the desktop and mobile space, we can expect both typographic finesse and artistic expressiveness to grow. As designers and developers expand fonts and design new ones, we’ll see a new challenge: exposing advanced typographic functionalities in a sane and balanced way, but avoiding overwhelming users with too many options.
- Who will be the first to take advantage of the flexibility of the gnome-shell to write extensions specifically tuned to advanced fonts capabilities?
- Will fonts be the focus of GSOC work as well?
- Will gnome-tweak-tool be extended to expose more font-related capabilities for the advanced typophile or designer using GNOME? Will some inspiration come fromfontmatrix ?
- Is a revamping of the font menu widget still planned?
- Will officially supporting a new language in GNOME include making sure the needed glyphs and behaviors are validated in the official GNOME UI font family?
- Will the upcoming Desktop Summit—held in Berlin, Germany, a city renowned for the high concentration of typographers and typophiles—push the envelope even further?
- Will other desktops using freedesktop.org open standards also embark on the project of picking and maintaining their own dedicated visual identity in the shape of an open font? Maybe just in the lettering of their logo?
Time will tell, but good ideas tend to spread…
Why not pick up fontforge and the rest of the open font design toolkit, learn its formidable feature set and start playing with your own branch of the Cantarell sources? Contributing to making it work perfectly in your own language? Contributing to weight variations? Adding advanced typographic features and smart behaviors? Joining an open font design workshop in your corner of the world? Have fun and happy open font hacking!
Nicolas Spalinger is the co-author of the Open Font License, maintains various open font packages, helps coordinate the Debian Fonts Task Force and the corresponding Ubuntu team, advocates FLOSS best practices to font designers and script engineers, contributes to release engineering of open font projects, contributes to the open font design toolkit and is a volunteer for SIL’s Non-Roman Script Initiative.
Follow the conversations of the open font community on planet.open-fonts.org.
Update: The editor apologizes for earlier errors. We’ve now corrected some code instructions and the names of several people and pieces of software.