GNOME Summit, day 2

October 8, 2007 – 9:23 am

I wanted to write a quick summary of yesterday … this isn’t going to be as detailed as my description of day 1, since I’m writing it while waiting for people to show up so we can start. On the other hand, with the beer summit last night, people might not be showing up too fast.

We started off yesterday with summaries as a group. Willie Walker gave an especially detailed summary of the work going on at the accessibility summit. Sounds like they are making good progress in figuring out a future transition away from Bonobo and ORBit and at improving the magnification facilities.

As on Saturday, most of the day was people hanging around talking and hacking, though there were some interesting sessions as well. Colin demo’ed Hotwire. As always, he had lots of really cool stuff to show, though I haven’t quite gotten over my reluctance to start over after 14 years of training myself on bash in a terminal. I’ll have to try it out again sometime soon. There was also a very well attended session on PulseAudio on GNOME in the afternoon, and probably a few more things that I’ll know about once we do the summaries today.

Behdad made it in today after spending Saturday at the Google SOC conference, so, as always I spent quite a bit of time talking to him about future Pango enhancements he has planned … figuring out a good API to load a specific font from a file, and optimizing the shaping process. (DejaVu has all these cool font features now, and we spend forever processing them, even for text where most of them don’t apply.)

After the the end of the day, everybody broke for the beer summit. Flat Top Johnny’s, where we had it, is a pool hall where we often have had GNOME release parties and local get-togethers in the past. We had a number of tables; the level of play by GNOMErs seemed to be notably low. (And yet lower when I was playing.) I left a bit before 11:00pm, so I’m not sure how late things ran.

The sessions already scheduled today have a certain naming similarity … we have a ConsoleKit / PolicyKit session, then a PackageKit demo session.

By Owen | Posted in Coding | Comments (1)

GNOME Summit, day 1

October 6, 2007 – 8:19 pm

Just got back home from day 1 of the GNOME Summit. So far, my overwhelming lesson is that if you put 50-odd GNOME hackers together in a couple rooms with power and network, they know exactly what they want to do. They want to a) hack and b) talk to each other. So, the bulk of the day was people doing exactly that. We had some good more-structured sessions, but they definitely weren’t the focus. I hope people will blog about what they were hacking on.

The venue: at the Royal Sonesta Hotel Boston has worked out well so far. The staff there really has the event thing down: when I got there this morning at 7:45, all the furniture, equipment, network, was set up exactly as ordered. Coffee appeared magically on schedule. And so forth. Beats the heck out of lugging a gigantic vat of Dunkin Donuts coffee in the back seat of my car, as I did a couple of years ago. Many thanks to Rosanna for getting this all arranged so well at the last moment. I do hope we can plan ahead a bit more next year and get a University venue as in past years … it’s certainly more cost effective, and also perhaps a more natural environment for hacking.

I attended three sessions during the day. My team from Red Hat had a session on the online desktop in the morning; we spent a lot of the time just demoing it. You never realize how much you’ve created until you stand up there and show it all. Then we had a good discussion about possible extensions and ecosystem issues. Thanks a lot to Asheesh from Creative Commons for keeping us honest and bringing up the question of how the online desktop relates to software freedom… it’s an important point. We can’t just think that a free shell to a bunch of closed web services is the end goal.

After that, there was a GNOME Love/Getting Started session that Thomas Hinkle suggested (Thomas is the author of the current Soduku in gnome-games, and hopefully much more in the future.) The concerns were pretty much what you would expect: the difficulty of getting things built, the lack of documentation about how everything fits together, patches languishing in bugzilla, and in general the difficulty of knowing how to go from having an itch to scratch to actually scratching it. One thing that was brought home to me personally was the value of the GNOME Love idea. I must admit that I’ve always secretly considered it just a bit wonky. What’s there to know? You just grab the sources, start coding, and if you hit a problem, you hop on #gtk+ and ask it. A view obviously highly colored by the fact that when I started out there were no experienced GNOME hackers. We were all puzzling out automake together. By the way, if you are in the Boston area, new to GNOME hacking, or just thinking about contributing you really should come down tomorrow or Monday. It’s free, there’s no registration, and a great way to get a feel for the community.

Then in the afternoon, I led a session on JHBuild, starting from some of my ideas in my last post. I don’t think anybody at the session other than me was a current user of JHBuild, so the discussion was a little theoretical. Which definitely drives home the need to revitalize building GNOME from the upstream sources as an activity in the GNOME community. The number one desire among the people there was making JHBuild better at building just part of the stack. Other things discussed: creating packages or vmware images from JHBuild results; installing JHBuild as a system package; build parallelization; building in a chroot or Mock environment to keep system dependencies predictable. David Zeuthen even suggested ‘jhbuild bisect’. One topic that got a lot of discussion was making it easy to try out a patch: given a patch in bugzilla, how do you make it easy for an end user to try out that patch, either by rebuilding their system package with the patch, or via JHBuild?

Talked to a lot of other people as well … talked to Travis Reitter and Robert McQueen about using online.gnome.org and the desktop data model to organize and merge together your contacts from the different Telepathy backends. Talked a bit to Jeffrey Stedfast about optimization of the use of Pango in Moonlight. And so forth. The fact that I was able to spend a lot the day in sessions and talking GNOME with people I think shows how smooth the setup has been. The only real issue was herding everybody out of the rooms at the end of the day. On the equipment list for next year: a megaphone and a sheep dog.

I wimped out and went home after the last session instead of sticking around and heading out to dinner, so I missed a lot more good discussion. Things start bright and early again tomorrow morning. The plan for the 9:00-10:00 slot is to have a “checkpoint” session to see how things are going. Come prepared with demos of cool things you’ve hacked up and suggestions for how we can make the next two days even better.

By Owen | Posted in Coding | Comments (2)

Upstream GNOME as a product

September 27, 2007 – 5:52 pm

GNOME releases chug right along: every 6 months we have a new release with a big slew of new features. But most of the changes are really narrow and incremental. It’s really hard to do a feature that requires changes in multiple places in the stack; that requires new API at the library level. This is especially true if the new API at the library level isn’t obviously useful.

As a simple example, some years ago, as I was working on polishing font rendering for Red Hat 8.0, I made the observation that there were very strong individual preferences as to font rendering. Some people wanted contrast above all else; other people were willing to accept a little fuzziness to get well formed and spaced letters. So, I wanted to offer a choice of “Best Shapes” or “Best Contrast” in the GNOME fonts control panel. This simple idea required patches to: the GNOME control panel, gnome-settings-daemon, GTK+ (the GUI toolkit), Pango (text layout), Xft (font display), FreeType (font rasterization), and the fonts.

Now, the entire patch set wasn’t that big … less than a thousand lines, I’d guess … and at that point I maintained two of the modules listed above (GTK+ and Pango) and was personal friends with the maintainers of most of the rest of the modules. But it was still a huge pain to get all the patches upstream, and for years, perhaps still, a lot of people on other distros had a control panel with the options of “Best Shapes” and “Best Contrast” that looked exactly the same. The only reason the change was at all feasible was because working at Red Hat, I was able to go ahead and add the patches to our packages without going upstream. I could create an example desktop where the idea was fully worked out.

Right now, there are two main ways to make a change that spans across many pieces of GNOME. One is to advocate a vision strongly enough that you can convince people in advance that it makes sense, and then get maintainers one-by-one to accept your patches . This works fine if you are a big name and a powerful arguer; if you can produce patches that are so clean, so nicely coded, so authoritative that they get accepted even if the big picture is fuzzy. It doesn’t work for newcomers to the project. The other is to work for a Linux distributor or create your own Linux distribution and make the changes at the packaging level rather than upstream. Which has its own problems, and doesn’t seem to be a generalizable model. How can we make GNOME more friendly to innovation that cuts across different modules?

To me, any progress here is predicated on being able to treat the GNOME desktop as a product, rather than as a bag of tools for people to build products with. There is no way I can get people to try out GNOME with my cool new patch set if the way they try out the standard GNOME is to wait for their distribution to ship the next version.

A basic barrier to trying out GNOME, whether standard or patched, is the complexity of the whole thing … jhbuild is a really cool tool, but when there are dozens (hundreds?) of modules from different source repositories with different version control systems in different languages using different build tools, something is going to break on almost any run of jhbuild, and you are going to have to be a wizard to fix it. Not to mention the pure time commitment for jhbuild. A fresh jhbuild will take the better part of a day.

One thing we should always keep in our heads is how do we reduce the complexity of GNOME. No matter how much well we manage the complexity, it isn’t going to help newcomers navigate their way around and productively make changes. Unfortunately, reduction of complexity is never easy, especially when trying to maintain compatibility. But we should try to figure out how to make sure that by GNOME-2.24, a build of the basic GNOME desktop doesn’t include ORBit, bonobo, audiofile, esound, libgnome, libgnomeui, and so forth. If that causes ABI breaks (say, a distribution has committed to the CORBA parts of the accessibility stack as stable API), then we need to figure out how to manage and message those breaks. In the past, I’ve been known to say that API/ABI compatibility is a black and white thing, you are compatible or you aren’t. We should explore the grays. And we need to clamp down on people introducing massive amounts of new complexity.

A more immediate thing we need to do is to create standard jhbuild configurations. If you looked at what operating systems GNOME developers are using, you’d find that a very small number of Linux distributions and versions count for almost all of them. Given that I was running jhbuild on Fedora 7, there’s no reason it should have downloaded and built fontconfig-2.4.1when fontconfig-2.4.2 was installed on the system. There’s no reason I should have had to figure out the need to install perl-XML-simple when the build broke with a message about XML::Simple. In fact, there was no reason I should have had to decide what directory I was going install into, create it, and muck with permissions. It should have been as simple as installing a yum repo file, then ‘yum install gnome-jhbuild-2.20; gnome-jhbuild-2.20 build <wait three hours>’. And given standard configurations, we can tinderbox these configurations and let people have a high degree of confidence that things will just work. (I don’t think this idea of standard for-the-distribution jhbuild configurations contradicts the idea I started with of custom-GNOME-variant build configurations. It should be orthogonal.)

Given a standard-per-distribution configuration, it’s 100% feasible to go further and have things like the ability to rsync the tinderbox build tree from the last nightly build to reduce the build time. But that’s gravy. Reducing build time is not as important as reducing the need for manual intervention.

Then finally, you need to make sure that there are easy ways to try out the new build. You should be able to fast-user-switch and log in to the new build without logging out of your current session.

The basic message here is that we should consider building GNOME from source not to be an esoteric and experts-only activity; we should design GNOME to make it easy, the same way we design GNOME to make it easy access your recent documents. If we couple that with attention to keeping the complexity within bounds, and then think about how someone could create “a branch of GNOME”, we’d greatly increase the possibility for substantive innovation.

By Owen | Posted in Coding | Comments (19)

A quick intro to the Mugshot data model

July 24, 2007 – 2:21 pm

One thing I’ve been working on over the last few months is creating a flexible way for software running within the online desktop to retrieve information from the server. I’ve been calling this the “data model”; it’s not a single piece of software, but rather a set of concepts, protocols, and software components that all fit together.

I posted an extended design document for the data model to the Mugshot mailing list before starting work on it. This post isn’t meant to be a substitute for that, or for a reference manual, but just to give a little taste of what the data model is about.

The basic concepts in the data model are resources and property. A resource represents some thing: a user, an application, an addressbook entry. It is identified by an URI like http://mugshot.org/o/user/61m76k3hGbRRFS (the resource for my user account on mugshot.org). A resource has properties, which are just values identified by names; a Mugshot user resource has properties called name, photoUrl, contacts, and so forth. (Yes, the name “resource” is borrowed from RDF.)

You get information about resources by making queries. A query is a bit like a HTTP GET; you send a query name and a list of parameters to the server, and get a list of resources as a result. Just getting a list of resource URIs isn’t that interesting, so you can also specify a “fetch string” with the query which says what property values to retrieve for each resource. If the property values point to additional resources, you can recursively specify what properties to retrieve from those resources. The most basic query is the ‘getResource’ query, which just gets property values from a single resource specified by its ID. For example, if you wanted to get my name and “home URL” from the mugshot.org server, and then also get the name and homeUrl for everybody in my contact list (my network), you could use the query:

 http://mugshot.org/p/system/getResource
   resourceId: http://mugshot.org/o/user/61m76k3hGbRRFS
   fetch: name;homeUrl;contacts [name;homeUrl]

The result from that is a list of resources and their properties; some of which are “direct” (query results), and some “indirect” (resources referenced by other resource properties)

  http://mugshot.org/o/user/hKcbRMYl4vNDqw (indirect)
     name: Colin
     homeUrl: http://mugshot.org/person?who=hKcbRMYl4vNDqw
  http://mugshot.org/o/user/gDmfAh8d7gXVRP (indirect)
     name: Havoc
     homeUrl: http://mugshot.org/person?who=gDmfAh8d7gXVRP
  http://mugshot.org/o/user/61m76k3hGbRRFS (direct)
     name: Owen
     homeUrl: http://mugshot.org/person?who=61m76k3hGbRRFS
     contacts: http://mugshot.org/o/user/gDmfAh8d7gXVRP
     contacts: http://mugshot.org/o/user/hKcbRMYl4vNDqw

The thing that goes a beyond a HTTP GET is that a query doesn’t just fetch property values, it also selects for future notification on those properties. So if Havoc changes his name on the server, I get notified immediately. This is important for the online desktop where there is no reload button and the user will expect information to just update by itself. Since the server tracks what it has sent the client, it can also avoid sending the same data over and over again.

I don’t want to go into a lot of detail here about how the protocol works, how you add properties to the data model in the server, or how you access the data model from client code, so I’ll just leave things here with a picture and a couple of code snippets. The picture:

Complete server code necessary to add the homeUrl property:

@DMProperty(defaultInclude=true, type=PropertyType.URL)
public String getHomeUrl() {
     return "/person?who=" + user.getId();
}

Client code in python for retrieving data from the model via the online desktop engine:

def on_got_self(resource):
    print resource.name, resource, resource.homeUrl
    for contact in resource.contacts:
        print "    ", contact.name, contact.homeUrl

model = DataModel()
query = model.query_resource(model.self_id, "name;homeUrl;contacts [name;homeUrl]")
query.add_handler(on_got_self)
query.execute()
By Owen | Posted in Coding | Comments Off on A quick intro to the Mugshot data model

Widget skeletons, GPU theming

July 20, 2007 – 12:42 pm

I agree 100% with Tim that using OpenGL directly as a rendering API for GTK+ makes no sense. The OpenGL 2D API is outdated and irrelevant; using the 3D API for acceleration of 2D is possible, but involves a lot of deep hackery; you want something like glitz to hide the details.

But does that mean there is no use for 3D rendering engines in the GTK+ world? I don’t think that’s the case. One idea I’ve been thinking about recently is that a 3D engine could provide a way of doing flexible theming in a way that is more accomodating of custom widgets than pixmap-based approaches. With a pixmap-based approach, if you know how to theme a button, that doesn’t tell you how to to theme something that is somewhat like a button. For example, imagine that you had a button separated into two parts with a shallow groove in between, similar to what you often see for a drop-down on a browser’s back button.

A theme that knows how to draw a button won’t know how to draw a button with a groove. But if the custom widget calls the theme API not as “draw a button”, but as “draw a button with this skeleton”, where the skeleton is a two-and-a-half dimension shape like:

Then the theme can apply textures, pixel shaders, and possibly transformations to the shape to get the final appearance. The same approach that produces a button from the basic box shape should produce something reasonable from the custom skeleton.

(A poor quality mockup in the GIMP.) Note that with pixel shaders, you aren’t restricted to pure 3D looks; it should be possible to get a flat high-contrast appearances if you want that. Another possible point of control for the theme engine would be modifying the skeleton a bit by, say, rounding off the corners.

This approach should allow a very wide range of themes; what it doesn’t allow easily is themes that reproduce anything that a graphics designer could possibly dream up and draw in the GIMP or Photoshop. So, it would be very important to have interactive user-friendly tools for theming that allow the graphics designer to play around, get a sense of the possibilities and create themes without having to go through the intermediatary of a programmer.

By Owen | Posted in Coding | Comments Off on Widget skeletons, GPU theming