Posts Tagged gnome

GNOME at SIGGRAPH 2006

So, as most have probably read, GNOME is at SIGGRAPH.

booth-5.jpg

The open-source pavilion from above

 

booth-2.jpg

GNOME and GIMP, but also Blender, Inkscape, Verse, Jahshaka…

 

booth-3.jpg

The graphics community has some of the highest standards for software, and open-source is fulfilling them

 

booth-6.jpg

AIGLX and Compiz: Turning virtual desktops and heads

 

booth-7.jpg

Jon Phillips teaching the world that vector graphics editing doesn’t have to be hard

Tags: ,

Tagging love and community ire

A couple days ago, searching for something cool to hack on, I came back to leaftag. Shortly after I started updating the deskbar handler, Luis Villa posted on his desire for it, and a release got cut. It’s pretty incomplete and buggy, and not very useful right now, but still enough to get a number of people excited.

However, it’s also enough for people to start giving us their opinions. I really don’t know why, but for some reason there’s a large group of people who really want us to use extended attributes to store the tags. Even after giving them a bunch of reasons why it’s not useful for our purposes, they keep trying to tell us how to build our bike shed.

I don’t understand why xattrs are such a big deal, and I don’t understand why everyone cares so much about how our implementation works. They’re never going to touch the code, and as long as it does what they want, why should they care what’s under the hood? I’ve set to see one comment on Christian’s blog that asked for a feature that required xattrs without first saying we should use xattrs. It really felt like all the features they listed were just attempts to justify their position that xattrs are the coolest thing since sliced cheese.

I’m starting to understand why Novell kept Xgl’s development under wraps until things worked.

Maybe I’m only starting to see something that has existed for years, but it really feels like gnome is so encumbered by endless talk, bike shedding and stop energy that very little is happening. The cool things like gimmie, deskbar, nautilus search and leaftag only happen when someone goes off in a corner, shuts themselves out from the community for a while and actually writes some code. The mailing lists and irc channels were recently aflurry with conversation about what “community development” means, and just as quickly as it came, it was gone. A huge amount of time and effort was invested into that discussion, and absolutely nothing came of it. This isn’t an unusual pattern.

I’ve heard it suggested by a couple people that gnome needs a dictator, and I really think that’s the case. At the very least, gnome needs someone who can tell people to shut up and get back to work.

And for all you xattr fanboys, code speaks a lot louder than words. Show us that xattrs provide something useful and good, and we’ll talk. Until then, shut up and get back to work.

I’m usually not one for movie quotations, but I’m considering adopting one as my mantra. “Fuck the bozos!”

Tags: , , ,

GNOME API documentation

No wonder GNOME (and linux?) doesn’t have very many ISVs. The platform really needs a new documentation system. Here’s why.

A couple weeks ago, while working on a gnome-vfs module for Chippy’s super-sexy tagging system, I noticed that gnome-python has no API documentation. No HTML, no docstrings, nothing. In order to find out a method signature, I had to look in the source code and decipher the python/C binding code.

Now, the python bindings are arguably somewhat further out in the gnome orbit. However, for an officially supported binding, this is pretty bad. The documentation for the C gnome-vfs API isn’t much better. When an ISV comes to gnome and takes a look at this, they’re going to run screaming. I know I did, and I’m willing to put up with a lot more of this crap because I know how hard it is.

How hard it is. Think about that for a moment. Setting up gtk-doc for a C module is a black art, full of copying strange build-system stuff and hours spent trying to figure out which XML files are auto-generated and which are safe to edit. If you’re lucky enough to be documenting something like gnome-python, all you have to do is write a bunch of docbook. Let me say it for the record: docbook is a total pain in the ass. I love the idea of using one source to generate HTML, pdf, etc all in one go. This is a well understood problem, and docbook is a great solution to it. Unfortunately, because docbook is such a pain to write, people aren’t doing it, and that’s the real problem.

I decided that because I was already taking the time to figure it out, I’d document it. gnome-vfs isn’t a huge API (and the python bindings are even smaller), yet it’s taking me at least two hours per object to get everything right.

The GNOME release team is requiring full API documentation for new modules, and that’s a step in the right direction from a policy standpoint. However, we need a lot of steps from a technical standpoint. gnome-vfs is pretty close to “fully documented” and yet completely impossible to use. Mono is doing something good here — anybody can edit API documentation, in a wiki-like manner; it’s not hard to find what to edit, and the commitment involved is minimal. I think if we got something similar across all of the GNOME platform (for every language), we might begin to see some real documentation. Writing API documentation isn’t hard. Writing API documentation using the current framework is a nightmare.

Tags: , , ,