From: http://gnomejournal.org/article/89/gnome-boston-summit-2009
Introduction Each year over Columbus Day weekend, GNOME developers — especially North Americans — gather for a casual hackfest in Boston, Massachusetts. The atmosphere is friendly and informal; most of the attendees know each other from other GNOME events. There are no booths at the event; companies are only represented by their employees.
This year’s Summit was especially productive. With a clear goal in sight (GNOME 3.0), everyone seemed to be on-task. Discussions were cordial and not too tangential. Ideas were rapidly brought up and filtered. New objectives were set and agreed upon. And, perhaps best of all, this Summit was very cohesive: almost everyone was able to attend every session that they needed to.
During and just after the summit, I posted notes on several sessions to my weblog—about 7,500 words worth. What follows is a much shorter summary of the Summit. I’ve left out the discussion to give you just the sessions’ conclusions and interesting factoids. Rather than a linear view of the Summit, I have provided an executive summary, merging like sessions where possible.
Logistics
Around 9:30 on the first day, Saturday, attendees began to wander into the MIT Sloan building in Cambridge, enjoying the coffee, tea and bagels provided by Red Hat (headquartered in Boston and well-represented at the Summit). The Summit began at 10AM with a short session, moderated by Jon McCann of Red Hat, in which attendees threw out ideas for half-hour or hourlong sessions. The attendees sorted proposals, voted on them, and scheduled the first two days of the Summit schedule, trying to ensure that popular sessions wouldn’t conflict. The last day, Monday, was reserved for hacking.
The Plumbing GTK+ 3.0 and Client-Side Decorations
Matthias Clasen talked about the plans to intentionally break the GTK+ API for GTK+ 3.0, and the new features the backwards incompability would allow: XInput2, the drawing API, and the ability to change theme engines without breaking applications. One goal was to make deep hacks less appealing, to put an end to the current string of abusive theme engines that must break with each new release of GNOME, and to provide a feature-rich foundation on which upstreams can do solid work.
Cody Russell discussed client-side-decorations (CSD), a feature which is already being developed on a side-branch. The authors aim to merge this work in time for GTK+ 3.0. CSD enables GTK+ support for things like Google Chrome’s tabs-in-window-decorator, and allows GTK+ to render the window border theme (rather than leaving it to the window manager). Cody said that he had been working with Nokia to ensure that Qt’s approach would be similar, to avoid compatibility issues between Qt and GTK+ applications that provide their own CSD. To ensure that windows can be closed even when frozen, some people have discussed extending EHWM to specify an area of the window that triggers “close” events. Having the CSD code handle resize events will prevent glitchy drawing when X11 windows resize before the border finishes drawing. There are no plans in the cards for a “Glib 3.”
Glib/D-Bus and GSettings
Ryan Lortie began with a brief history of some existing methods for D-Bus access in GNOME. gbus was a libdbus replacement based on gvariant, libdbus being the core protocol library that the daemon, and the glib, Qt, python bindings, use. Two different people had worked on implementations called “gbus” and another on eggdbus. These implementations are not good enough, and Ryan proposed three steps to move forward.
merge GVariant (G-ified D-Bus’s data types) into Glib have libgio link to libdbus1, possibly via a GIO module extension point pick some of the best parts of gbus and eggbus and merge them into GIO as GDBus At Colin Walters’ request, it was agreed that this new binding would get filtering and path registration. The attendees also agreed that it would be a good idea to put libunique in GIO on top of this new binding.
Ryan then demonstrated GSettings and its API. At the time, GSettings was a proposed replacement for gconf; it has since been accepted. Participants said they wanted to add Gsettings to GIO, too, after GVariant was merged. GSettings uses atomic changed signals to change many settings at once, rather than a signal for each setting. GSettings’ signals do prevent recursion, and a feature was planned to allow filtering returned signals. The GSettings schema format is a simple plain text file (in a python-ish format with indentation and colons). GSettings supports inheritance, as expressed in the schema format (schema inheritance).
Ryan demonstrated dconf as a replacement for gconf (the daemon that merges application writes into the on-disk data-store). He went over the simple API as it stood then. Compared to gconf, dconf was 10-50 times faster on reads, and had high-performance writes as well. Not only is dconf’s memory usage an order of magnitude smaller than gconf, but dconf is only in memory during the writing process. The dconf writer process uses fsync() a lot, but you don’t care because it’s not blocking your application.
To perform regression tests of applications which use dconf, one would set proxy settings in gconf/dconf without affecting the user session, or use a custom GSettings plugin can redirect the requests to a temporary database. Ryan said he’d be adding PolKit support soon.
For distributions that override upstream defaults in the distro packager, Ryan suggested modifying the schema via a package patch, rather than adding vendor-specific defaults databases to the system (aside from the standard default database).
Finally, the session wrapped up with a few details. NFS home directories with dconf were buggy because using mmap() over nfs is generally ill-defined, but Ryan was working on it and committed to finding a solution; the documentation would soon be going up on library.gnome.org, including some documentation on how to migrate modules. A gconf-to-dconf bridge was also in-progress. The bridge ran some simple applications, but there were some serious problems to solve. Ryan needed and still needs help, especially with this part.
Hallway Track: GTK+ Font Dialog Revamp
via Alberto Ruiz Alberto Ruiz and Máirín Duffy teamed up to improve the usability of the Font Dialog. Máirín did some mockups, Alberto implemented them in pygtk, and they ran usability tests with the prototypes. They promised a first prototype within a week, and a few days later, Máirín posted the mockups and prototype and asked for comments .
GObject Introspection
Colin Walters started the session with a short introduction to GObject introspection. In Colin’s opinion, GObject was ripe for this treatment: the type system already had a lot of prerequisites for an introspection tool, thanks to features designed to make it easier for us to script our C libraries. We needed a few more things, though—mostly annotations. To that end, Colin demonstrated how to annotate C libraries to make them accessible from GObject Introspection. This annotation data declares (for example) what containers were being passed around by which pointers, and whether you, the consumer, would need to unreference the pointers when done.
When you run the annotation parser, an XML document is written to a .gir file; the .gir is then compiled to a .typelib, an efficient binary format containing the same information. These two parts would make a language binding work. Several language bindings were being worked on, and a GJS binding was already ready. PyBank, the GOI-based Python binding, was fairly complete at the time, though some call conventions had to be worked out for compatibility. Colin thought that the legacy bindings that had already been written shouldn’t be replaced. New bindings should use PyBank, and PyBank will preserve call compatibility between the old and new bindings.
Colin was looking forward to the day that gtkdocs were supplemented by annotation data, but some work remained to get to that point. As a closing thought, Colin left us with the suggestion to try polyglot programming in a project: just by using GObject, you would already be 85% of the way there.
Clutter 1.2 API
This session discussed API additions wanted for Clutter 1.2. Emmanuele Bassi listed some highly visible new features: texture atlasing, a unified texture cache, and layout management. Emmanuele was thinking of adding a modular plug-in architecture to handle input methods, similar to the one used by GIO: API stubs that could be implemented in inherited classes. This would allow nearly any functionality added via GtkModules to be re-implemented in ClutterModules.
Some upcoming performance work was also noteworthy. Ongoing work on frame buffer objects would make partial uploads of changed windows more efficient (for example, when the Evolution throbber is running, there’s no reason to upload the entire window again – we should just upload the changed sections of a texture), but there was no estimated completion date. A lot of people were working on getting VSync to work correctly on top of a GL window manager on top of buggy hardware. The problem lay deep in the hardware drivers and sometimes the hardware itself. There were three separate ideas about how to improve the performance of finding which object the end-user clicked on.
Emmanuele closed the session by getting a sense of the attendees that Clutter and GTK+ could peacefully coexist, targetting different kinds of applications and both having the full support of GNOME. By sharing code where possible and providing a usability guide, API references, and programming guides for each toolkit, we can provide a rich, diverse platform in which Clutter and GTK+ apps can fit together, and in which any type of application is possible.
GNOME Shell Jon McCann from Red Hat ran the first Shell session, on design. An amazing amount of progress had been made since the hackfast one year prior that spawned the Shell project, but some major tasks remained. Fortunately, Red Hat decided to fund full-time work on the Shell, so progress was being made quickly (and still is).
Jon focused on the Shell UI as it stood then, and still is today. He said that the top bar had been redesigned. The right-hand side showed session-oriented actions (things that would apply to the entire session). A clock and date widget were in the center, “balancing” the top bar to provide an even distribution of content across the width of the screen. The far left-hand side held the “Activities” menu, which activated an overview mode. Between “Activities” and the clock widget, a dropdown menu would show the current application.
Some examples of session-oriented actions:
Your presence (now implemented) Login and -out Messaging The control center Your own account information The notification tray stays in the same area as the session-oriented menu, but with encouragement to use a new messaging API that would display it in a different location.
The overview mode accessed through the “Activities” menu is a work-space layout view similar to Expose. Work-spaces will not be forced on users, but would be immediately accessible should a user choose them: by default, there will be only one work-space. This would prevent a user from accidentally hitting the “switch work-space” hot-key, having all their windows vanish, and panicking. The left-hand pane of the overview mode displays a search box, lists of your favorite and of all applications, recent documents, and bookmarked places (from Nautilus/GIO).
The new UI is application-based, and displays the current application in the top bar. There were plans for a new API that would show application-level actions: quit, preferences, new window, etc. The Shell requests a new window from any application by invoking the binary again (hoping that it uses libunique or a variant). The new Alt-Tab interface also cycled among applications, with Alt-` showing an extended view of the individual windows grouped beneath their application icon. Mouse navigation and mouse wheel access is also possible in the Alt-Tab UI.
Owen Taylor was concerned about the discoverability of the session menu and offered one proposed solution: a help bubble on first login that would say “Click here to set your name.”
The overview search was an open problem at the time. Then, only menus, recent docs, and places were searchable. Since then, a semi-formal commitment has been made to allow plugable search back-ends.
A major objective that was just beginning was messaging: everyone was tired of having chat, SELinux, etc. stealing application focus. Canonical deserved credit for trying to solve this in GNOME 2, and the messaging design was inspired by this earlier work. Since the Summit, an initial implementation has been committed to a public branch. A message queue in the lower right hand-corner displays things waiting for your attention: chat applications, mail notification, system warnings and music players. Unlike with the notification area, acknowledging receipt of a message is not the only way to get rid of it: a “message” can be suppressed temporarily without discarding it.
Newly arriving notifications slide up from the bottom of the display to show a single line of text, remain for three seconds, and then slide out. To see the pending messages needing your attention, you can move your mouse to the lower right corner and the message queue will slide in. You can also examine the message queue in the overview mode.
Telepathy chat apps add a simple reply window to their message notification, so that an interruption can be immediately taken care of and the user can return to their primary focus. The IM client itself will continue to handle more involved chat. A libnotify compatibility layer is implemented to support legacy applications.
Owen Taylor and Colin Walters opened the second session about Shell: tech. Colin showed how the internals of Mutter became accessible to GJS/Javascript inside the GNOME Shell’s Mutter plug-in. He demonstrated the interactive JavaScript console inside GNOME Shell and used the Looking Glass tool to inspect the stage, to get a reference the the JS object associated with an actor, and to change its properties.
Owen took over and showed how to take the property you just changed, change it in the code on-disk and then type “restart” to reload the shell with your new code—no compiling. He also demonstrated changing the CSS file for the calendar widget and then restarting the shell. At the time of this writing, the majority of the UI is theme-able with CSS. Shell’s CSS implementation stays as close as possible to the behavior that you’d expect on the web, making it easier for new people to understand. The Shell Toolkit also supports inheritance of CSS properties.
Accessibility then came up. Owen said that once Clutter and the Shell Toolkit were accessible, very little work would remain. There was a new magnifier inside Shell that was already being implemented. Someone asked about “Show the Desktop”. That elicited a slightly sheepish response: they didn’t really know what to do about it then. As it stood, “Show the Desktop” sucked. If you were to accidentally click on the desktop and press Delete, you would delete a file. There was some thinking that showing the desktop at all would be a bad idea. Since Summit, Alex Larson and others have been discussing this on the mailing list.
Jon McCann said that they would like to manage tabs within applications at the Shell level, and that some application API was needed to make this happen. For example, it would not really make sense to group GMail with the rest of your browser tabs. One idea was to support single-instance tabs: clicking your GMail icon would yield your existing GMail tab if you already had GMail open. Obviously this problem requires some cooperation from the browser. Another idea was to filter all tabs at the level of the Shell, allowing you to pick a tab from the overlay. The GtkNotebook widget could communicate this to the Shell. Another useful feature would be to allow you to search window titles with the search bar.
The developers gave a short list of things to work on: the messaging tray (already partially implemented), application browsing in the “More” menu (just rewritten), recent documents, people-based search results, fly-over pop-ups for more information, the sidebar, the application menu (on the top bar) and extensions.
Owen and Colin saw existing panel applets as a multi-faceted problem. Things like Keyboard Layout applet would need to become first-class citizens. On the other hand, the Deskbar could be removed if the search field were made extensible. Other plugins, like a stock ticker, would need to be sidebar extensions.
Miscellaneous Splinter and git bz
Owen opened the session by demoing Splinter, the web UI for reviewing patches.
Splinter’s UI makes it easier to add your own comments and to view other people’s comments in context with the code. The UI provides a patch view in which clicking a line adds an annotation.
Splinter stores the results in a normal Bugzilla comment that is human readable and parseable by the Bugzilla extension. As you work, Splinter stores your work in DOM storage so you won’t lose it if your browser crashes.
Owen said that he didn’t intend to push it upstream, but to advocate and push it as an extension‚ especially to the Bugzillas he is forced to use.
Owen then spoke on git bz, the git bridge to Bugzilla that allows users to post patches for review. In response to requests for a branch-per-bug, Owen said that this would be hard because, for example, what would happen on a git bz pull in this branch? Would it pull the current bug status?
Owen said he thought that git bz would never move upstream: git bz is in Python and upstream is C, Perl and lots of Shell.
GNOME Women Outreach / Marketing
Marina Zhurakhinskaya from Red Hat ran the session.
In 2006, a Google-supported, 3-slot version of Summer of Code was run exclusively for women. Marina said that the Board would like to repeat that using GNOME Foundation funds. The first task would be to contact the women who participated in the 2006 program and get an idea of where they stood today regarding open source involvement. (Since the Summit, GNOME Journal has published an article about this very topic.) Some people had a perception that, generally, these programs work best when they select participants who have already contributed in some regard. Marina said that this has been a challenge, because there haven’t been a lot of women in GNOME.
The second task would be developing better introductory materials for both GSoC and Women’s Outreach. Earlier meetings had suggested making resources for students that mentors should review. For example, a mentor should introduce their student to certain aspects of the GNOME community, such as IRC and Planet GNOME—the social side of things. Also, we shouldn’t make it a scavenger hunt for students to find the the technical documents they need to accomplish their goals.
Third would be proactively finding students by contacting universities and asking: “Do you have students who would fit this Women Outreach program?” This could make a huge difference in the level of participation.
Finally, another focus area would be finding mentors and working with them before the program starts. (You can sign up as a possible mentor.)
An attendee pointed out that, generally, we have been bad about helping new contributors, regardless of gender. Most of us haven’t had time to do handholding for new contributors with no experience. Everyone agreed to revive GNOME Love. Everyone remembered this being a success, until the people (or person) providing the man-power could no longer run it.
A proposal for an effort to get more Windows-to-GNOME conversions started a segue to the topic of marketing. Some wondered whether GNOME should even be brought up in such a conversation, pointing to a “What is a web browser?” video that Google had published the previous week. Since five of the six most popular distros gave users GNOME by default, most people would have no idea that they’re using GNOME, not having selected it.
The discussion got very lively at this point, switching among many tangential topics. Some argued that advertising should be only a tiny portion of marketing, and that a huge part of marketing has been listening to users and implementing what they want. One person pointed out that many people have started tweeting their frustrations, allowing us to mine social networks for “hot spots” of usability problems, and even to engage users directly and help them solve their issues.
There was disagreement about which message to emphasize in advertising: cool stuff you could do with free software, or freedom itself. One participant mentioned iPhone commercials as a good example of showing off cool stuff that makes people want to have the product. This tangent was tabled but there appeared to be agreement that short videos would be better than introductory documents.
We returned to the theme of trying to get more users and there was agreement that it’s a very hard task to accomplish. A point was raised that, as with hybrid cars, a portion of the population would respond to a message that “this is good for the world.” There was agreement that this would work for some, but not all audiences. The discussion ran out of time, but the GNOME Marketing Hackfest several weeks later took up most of its themes.
Telepathy BoF (Will Thompson)
I attended this Birds-of-a-Feather session. Below you’ll find my summary of Will Thompson’s session notes.
The session opened with a discussion about gnome-games’ tubes code, which was broken when Empathy moved to Mission Control 5. Developers were working at the time to get it working again, and are working still. Making gnome-games use a newly written contact selector widget that supports MC5 will get it to work again; this selector could also form the basis of the long-anticipated telepathy-gtk.
The Tubes API currently makes it difficult to request a channel for yourself. Empathy contains helper code to make this easier, code that can be moved the telepathy-glib.
We discussed new ways to use Telepathy. I wanted a way to share high scores with your contacts, and they suggested using tubes. The design: gnome-games would come with a tiny daemon that would handle tubes for the “org.gnome.games.highscores” service, serving up your high scores to any contact who asks (if you select “Share my scores with my contacts”). When you open your high scores table, it would use ContactCapabilities to discover which of your online contacts supportted that service, and then would ask them for their latest high scores (with a cache and a rate limit).
Sjoerd noted that Danielle had written a helper which would let you say: “give me a stream to this person,” and that this could conceivably be extended to set up a socket automatically. gnome-games will be documenting how they’re using tubes. Rob suggested pushing this into telepathy-book.
John Palmeri suggested another way to improve documentation: make writing documentation a requirement for Google Summer of Code. Sandy said they’d been discussing documenting requirements and standards for GSoC students, and thought that it would be a great idea to ask students to blog stream-of-consciousness “this is what I did” updates. People would have to make sure that they do this as they go along, because you would forget the learning process after a few weeks.
Rob noted that Telepathy hackers know that you would need to use, e.g., a Handler and a Tube, but people who aren’t immersed in the stack have a lot of prerequisites to learn in order to understand that stuff.
The conversation moved on to other possible uses for Telepathy tubes: integration with DevHelp would be nice to let people post examples.
A closing thought on the future Telepathy tubes was that it should use UPnP to make file transfer and tubes fast in more cases. This was very much on the to-do list.
Geolocation with Emerillon
Pierre-Luc Beaudoin ran this session on Emerillon, the map and location application. It is available and in GNOME git. Pierre-Luc demonstrated Emerillon and libchamplain (the map widget) for the audience.
With Emerillon, when browsers and websites request your geolocation, a dialog prompts you before sending your location to the requester, giving you control over your privacy.
Pierre-Luc envisioned several uses, immediate ones including viewing contacts on a map or geotagging photos. Other ideas included updating social networking apps with your geotag on Twitter. Some suggested integrating with Mojito on Moblin.
Pierre-Luc said that OpenStreetMaps was offering pixmap tiles, but there was a GSoC project to download the meta-data in raw XML format and render it via Cairo, locally. Pierre-Luc said that OSM’s servers were rather overloaded. Ted Gould from Canonical suggested pre-seeding the cache with all North American data, for example, for a netbook. To let Emerillon submit edits to OSM, use the right-click menu to open OSM in a browser and edit the data.
Pierre-Luc demonstrated some comparisons of OpenStreetMap with other online maps. There were som cases where the data in OSM was clearly better. He demonstrated how geographical data is integrated, as well as public transit (mostly in Europe).
He requested that everyone give Emerillon a try.
Usability Kit
The session began with a demo of the “usability kit” developed by Máirín Duffy and Ray Strode. The usability kit records the keyboard, screen, and the user’s face. The box contains a DVR-style device, running embedded Linux, which stores all four video inputs. The total cost of all hardware, including VGA scan converter, was $800.
The user’s behavior was recorded as they performed a set of tasks given by the test giver. The analysis was done after-the-fact by filling in the user’s behavior while he was attempting to complete the task. The videos have provided actual documentation of the lag between a user’s click and UI’s response (especially helpful for a web site design).
Máirín tested a wide range of users, from developers to regular users.
Máirín recommended narrowing the testing scope to a specific set of tasks. Rather than saying, “I’m going to test GNOME,” narrow it down to “File Management” and then come up with a list of tasks related to that. Then measure those.
Ray finished the session by showing how they used GStreamer to stitch the four separate video feeds in to a single video. In a subsequent blog post he explained how this was achieved:
“The DVR hardware in the setup ouputs four AVI files—one for each camera.” “It’s possible to write a pipeline that can take the 4 videos and compose them together into one 4-way split screen. ” “Someone here at the summit asked for me to check it into git, so I did that today in the usability-lab module.” Summary The GNOME 3.0-specific sessions dominated hallway and dinner conversations; this was clearly where the excitement was at. GNOME Shell was a major factor, but many were excited by other upcoming changes, like GSettings and even the client-side windows work. The sense of momentum was palpable and this energy has carried us forward for the past two months. Thanks to the success of the Boston Summit 2009, we’ve made major progress towards our objectives, and have positively influenced other teams and hackfests.