cgwalters

FUDCon Toronto, on the bus

2009-12-07T16:06:19Z

At FUDCon Toronto 2009, finally got a reliable connection at the hack room to give an update. On the bus from Westford to Toronto, I spent some time optimizing the GNOME Shell JavaScript engine Gjs, specifically how we do invocations from JavaScript into our C core.

As always, sysprof is an a great tool, and revealed we had some relatively low-hanging fruit. (Side note - in Fedora 12, sysprof no longer requires an external kernel module, which is awesome). Said fruit was partly in Gjs, partly in the GObject Introspection layer. We could clearly be doing more caching in the latter, but Gjs was also using the basically toy/demo invocation function g_function_info_invoke.

I've now got it so the invoker can take a bunch of JavaScript jsval pointers, and schlep them more directly into libffi argument types. The end result is currently a 25% speedup on my benchmark, which is fairly good as far as 5 hours in performance work goes. I'm now looking at some other bits, and I think I'll be able to squeeze out another 7-10% at least with just another hour or two of work.

Now, in the the farther future, I could imagine teaching SpiderMonkey's JIT compiler about how to invoke directly from JS to C (and the reverse); the amount of generic work we still do to take say a single double across is fairly high, but the JIT could know about the platform ABI, and be able to trace right up until a native method, which would be a large speedup.

And for now, I'll leave you with a picture of a tasty waffle from this morning:

From FUDCon Toronto 2009

Netbook in the coal mine

2009-12-02T21:52:37Z

For a long time my primary workstation was a (now 3 year old) Dell Inspiron E1705, or "bricktop" as ajax liked to call it. However the hinge broke a while ago when I closed my car door while the bag was too close, and when the laptop started to fall apart I decided to get a new machine. Actually, I got two. The first thing I did was get a serious desktop computer, a Dell XPS 630. It's quite a beast, especially since I got 8GB of RAM with it. I pretty typically have over 2GB of memory used purely for page cache, which is probably my entire working set of files. It's hooked up to a nice 24" Dell 1920x1200 monitor. This computer is named megatron.

Needless to say, the machine is fast and nice to use. However, it's rather unrepresentative of the general personal computing space. So I wanted another machine that was mobile, and also closer to what "most" people use. So I picked up a MSI Wind U123, known as pocket. It has just 1GB of RAM, which is probably the realistic minimum we want to support going forward (ideally we'd be workable with 512MB, and we probably are if you're just running one application or one or two websites, but...). The machine also has an Intel 945 video, which is also near the lowest end graphics card we'll be supporting for GNOME Shell.

The difference between the two computers is rather extreme, but I use the netbook very often, and working on it has forced me to optimize some things in the shell. It serves a similar role for performance issues that canaries used to do in coal mines (hence the title of this post). Specifically, I've been working on search performance, with fairly good results. We had a few sillies in the old search system like creating lots and lots of ClutterActors we'd never display, not caching lowercased strings, etc. (the other goal by the way of my search work is to move us closer to the current search mockup, which should be cool).

But the biggest performance problem I've been running into so far is synchronous I/O. A lot of GNOME libraries like gnome-menus were designed for gnome-panel, which typically you don't interact with often, and so it's not a big deal if the process is blocked. However if the shell is blocked, because we're acting as a compositor, we won't repaint the desktop or process input, which is a serious user experience problem. An example of this was that we would synchronously stat (check for existence) of recent documents; this could easily take several hundred milliseconds if the data isn't currently in the kernel cache.

I've been reworking our docs handling specifically to be smarter; we use async I/O now, and only stat ones we're actually going to show in the UI. We could be smarter still, but this has helped a lot. GIO has really nice APIs for this kind of thing.

I mention this for two reasons; first, just because you might be interested in a status update on Shell work. The second is because I'm hoping to Real Soon Now land my extension system patch, so if you create an extension using it, for a good user experience, you'll need to be very careful about I/O too =)

It's coming

2009-10-13T03:36:59Z

GNOME Summit went really well, and I had a great time. One thing that I was really heartened to see is that we've agreed on a GLib/dbus plan, and this will enable a number of cool things. First, dbus-glib is just not very good, and we've needed a better story. I hadn't realized before just how much nicer GVariant can make doing DBus calls. But beyond that, having DBus underneath the GTK+ stack will better unlock things like GApplication which will in turn let us do nifty things like exporting GtkAction over the bus. If that's still a bit abstract, look at say Stuart Langridge's post on Linglish.

Pay no attention to the processes and X Windows behind the curtain...

2009-09-02T00:06:46Z

A major change we're trying in the GNOME 3 Shell is to be application-based instead of window-based. In this we'll be in good company with newer releases of other operating systems, but it's still a major change. What I want to explain in this blog entry is what that means from a user perspective. For the developer perspective, see this wiki page.

Let's first look at one of the most venerable (and yet apparently still obligatory) applications, the Calculator. In GNOME 2, launching the calculator looks like this:

From GNOME Shell

Launching Calculator

When we click on that menu entry, the application is started (for more details about under the hood, see the linked wiki page above). The visual result is this:

From GNOME Shell

Calculator and the window list entry

There's a window for the application, and a task list entry. Now in GNOME 2, if we go to the menu and choose Calculator again, we get this:

From GNOME Shell

Two calculators

Technical people will know that under the covers, there are two gcalctool processes, each of which is creating one window. What this example emphasizes is that in GNOME 2, the bottom panel has a list of windows (or tasks), not applications.

Moving on to GNOME Shell, the "window list" and "menus" part are merged into the overview. Let's take a look at the application well when Calculator is not launched:

From GNOME Shell

GNOME Shell overview application well

Here I've added Calculator to my favorites, so it always shows up. It's not running yet. When I click on it, the active application at the top immediately changes to show that (GNOME techies: this replaces startup notification), and then the widow appears:

From GNOME Shell

Running Calculator in GNOME Shell

So now that Calculator is running, let's go back to the overview and see what changed there.

From GNOME Shell

Application well, with Calculator running

You can see that the Calculator gained a glowing status indication, like the other applications I had running already. When I click on that icon again, I am switched to the running calculator window:

From GNOME Shell

Looks exactly the same!

In other words, it looks exactly the same, it just shows you the window again. (Under the hood, the program is not re-executed, there won't be multiple gcalctool processes, etc.)

Ok you say, but Calculator is a pretty boring application and you don't use it anyways. How am I making your life better? Well, there are two major things.

One of them is that many programs fail in some obvious and other times less than obvious ways if you click the menu entry twice in GNOME 2 (technically, by default this will start two processes). They'll overwrite each other's data, etc. For very few instances does it make sense to have multiple if the app is not explicitly designed for it, and this will avoid you accidentally launching two. Personally I get annoyed when I accidentally launch two xchat-gnome instances and appear on IRC twice.

The second improvement here will come when we get a bit better application integration; the mockup we'd like to implement for say Firefox and multiple windows looks like this:

From GNOME Shell

This needs application-specific work though.

As a brief unrelated aside, I think recent Chromium builds with the tabs-in-window borders (technically, client side decorations) looks cool fullscreen in GNOME Shell with the application menu:

From GNOME Shell

Chromium in GNOME Shell

Next post I'll talk about how GNOME Shell will save you time and get you back into your applications faster.

This work is licensed under a Creative Commons Attribution 3.0 United States License.

Just when you think you have a good idea...

2009-08-14T17:42:40Z

...it turns out someone on the Interwebs already did it. Curse you interwebs for how easily you crush one's brief pretensions to originality. Anyways, in GNOME Shell we finally got bug 589652 in which means we're ready for translations! We don't have a lot of strings, but it'd be good to get the ones we have translated for 2.28. Ready, set, go! I've given French a leg up with a translation for Activites as a test case.

Along the way it took a bit of gjs hacking to make it easier to create native modules; if you found yourself embedding Spidermonkey but yearning for PyArg_ParseTuple, gjs_parse_args is your friend.

Speaking of programmer stuff, the built-in console mentioned in my previous post gained a parent-list inspector and property inspector which bring it very slightly closer to Firebug-like real, ultimate power. True story, I originally called it lookingGlass.js completely forgetting about Sun's project ironically also about 3D-based desktops. Anyways, since that doesn't seem to be actively developed anymore, and it's a really great name, I think I'll just...if you don't mind....(yoink!) claim that name.

There have been a lot of other user-visible changes recently, in visual terms I really like the result of both Sander's excellent work in bug 584609 in combination with the progress recently on moving visually to the mockup Jon referenced here. Another promising change is our start on the application menu area.

Which gets me to the subject of the next blog post; one the major changes in GNOME 3 from both a user experience point of view and application developer view is that we're application based, not task based. Work continues in this area - in the next post I'll talk about how this affects the experience.

It's hot

2009-08-02T11:58:03Z

It's hot and humid in Boston, and I've been finding it a bit hard to sleep sometimes. I keep telling myself I'm going to get an air conditioner, but, well, laziness and money. Anyways tonight around 3am I just gave up, and from then till now-ish I was working on this cool little hack for Gnome Shell.

So here's the problem. I have almost no visual skills personally, and in a freeform environment like Clutter or HTML I have a really tough time making things I code look good without basically being handed the pixels directly by a visual designer. But one thing I have noticed though is we have some people in the GNOME community with awesome visual skills. So I wanted to lower the barrier to entry a bit for them.

My inspiration was Firebug (which again if you have to do HTML and haven't tried, do so immediately); I wanted to make something where you could interactively edit and debug the visual layout. So the result of the hacking landed in bug 590515. But since you're unlikely to do a git pull and git bz apply, I used Owen's cool builtin facility for making .ogg recordings of the shell.

Note however that at least parts of the shell aren't redrawing correctly in the beginning, and I gave up debugging that for now. The top chrome will appear in the middle of the video.

Ok, you don't have the video tag, try the direct link.

Being able to hack something like this up in a short span of time is really neat I think, and definitely is one of the high points of having one's app scripted with JavaScript. You can go in and play around, even monkey patch things.

To actually make this useful for artists there's a lot more to do; a Firebug style properties display/layout debugger probably wouldn't be too hard, and would help you get past the problem of even knowing what properties there are. But besides this tool, in the big picture we really need to switch to CSS, but that's coming.

One question you may have is why when I moused over the window area, we didn't see different boxes for the windows? Well, that comes down to the fact that there's a transparent input-only box over the windows. A nice future enhancement for this tool would be to be able to skip layers; then you could type in a bit of code and animate/color etc. your windows.

Another thing that would be neat from a code perspective to make this more useful for hackers is to allow JavaScript subclassing GObject; the problem is most of the shell there's no good way to get the JavaScript framework from a given actor. If only I had a time machine to go back to when Brendan was typing in code for prototypes, and hand him an extends keyword. But, speaking of dreaming...it's 8am now.

There's more going on in the shell land, among other things we're taskbar-less now. Yay for less visual chrome, though we have to work through the details. More on this later.

git-un-diff-whitespace

2009-07-21T20:21:12Z

So among the major burning problems we have in Free Software, one of the biggest is trailing whitespace in source files. If you too have a project where people really care about this, you may be interested in my quickly hacked up git-un-diff-whitespace script. It removes trailing whitespace *only* in areas modified by "git diff" (i.e. it won't pollute your diffs with lots of spurious whitespace changes). I briefly tried to find something like this elsewhere on the interwebs but failed. Oh, and if someone fixes it to handle new files I'd be happy.

Full experience

2009-07-20T15:09:40Z

One of the things I wanted to talk about more was what I think does matter about the desktop, which is the total experience and how it relates to branding. People with extensive computer experience have a significantly better understanding of the individual components in a system (though they can and often are wrong of course about details), but the problem is that this leads to a different experience than someone without that understanding.

A specific example I'm thinking of here is the Java updater on Windows. I overheard one Java developer expressing surprise that someone they knew without much computer experience thought Java was a pop up. Now you may laugh, but really, they're not wrong. The pop up is their total experience. People with the computer knowledge know they need it to play some online game, or they don't. They know it's from a different company, and added on by the hardware vendor, or that the pop up is a tiny piece of a much larger system. It ends up being a very different brand.

Speaking of hardware vendors and brands, this brings me to Windows itself. I've kept around a Windows install on my PC for various reasons, among them that I like to keep up to date on what's happening in Windows land and be able to carry on an intelligent discussion about operating systems in general (not that you can tell from some coffee-fueled rambling blog posts), and also because I'll probably have to work on porting GObject Introspection to Windows (pure pain) at some point. So here's the problem with the Windows brand, and I think Microsoft is catching on to this - you're carpet bombed with it in your interaction with the system, and it's associated with very good things, very bad things, and everything between. Some things that are Microsoft's fault, and some things that aren't.

I was browsing the menu one day and came upon a Windows Dancer menu item. Microsoft made this, associated it with the Windows brand, and shipped it. It boggles my mind. Did you know that 29% of Windows kernel crashes are caused by NVidia? Except here's the problem - it just says "Windows crashed". So the user is going to associate that crash with the Windows brand, even though it it's really not Microsoft's fault. By far my favorite though is the Dell Dock. Definitely a lesson there in letting hardware vendors do arbitrary things to one's OS.

The point here is that the design and experience of Microsoft's core system (or any operating system) in a vacuum are far less relevant than the total experience of someone who just gets a computer. And this I think is actually a strength of the free software operating system, for a few reasons. Following the "rough consensus and working code" approach inherently avoids the worst things. If someone proposed a Message from your mouse vendor pop up in GNOME, we'd just laugh. Second, because we're fundamentally cooperative, there's less tension about replacing higher level things that people try to add on top. If memory serves correctly, for years Windows didn't ship with an unzip utility in the core OS, presumably because of concerns about undercutting Winzip. We'll never have that problem.

A bit more on this later, and how it relates to a feature I'd like to work on for the shell.

Uncanny valley? I don't think so.

2009-07-18T21:44:05Z

So Henri Bergius discussed John Gruber's claim that the free desktops are in an uncanny valley. Let's leave aside the obvious bits that 1) desktops are absolutely nothing like robots trying to be people, and 2) clearly the fundamental basis of the uncanny valley is the "Pathogen avoidance/mate selection", since in the tenth of a second it takes for your reaction to form, you obviously don't have any time to ponder "Western constructions of human identity". Given that people don't get pathogens from their computer (unless you're using a public internet terminal) nor attempt to mate with them (no comment), the uncanny valley isn't very useful as an analogy.

That said, it's amazing to me that John managed to go on for so long about operating systems in general (not just desktops) without mentioning the most important point about them. Actually, really the point, which dwarfs all others. That is:

To run the applications you want

Now, don't get me wrong. There's a lot of details about desktop operating systems that are important; more on this in a minute. Obviously, a web browser is essential, but that's a commodity. Now, I don't want to get into a debate about exactly what percentage of people can be fully served by solely a web browser, but let me just note that for a lot of people, especially ones with overseas families, Skype is still a killer app. And you can't write Skype in the default web security model (which is the relevant bit here, not a missing-the-point debate about AJAX versus platform widgets).

Continuing on the subject of the uncanny valley, clarkbw told me a while ago there's been HCI research to the effect that people are not generally too troubled by visual differences. Consider for example the evolution of the Start menu; it looks really different between each of Windows 2000, XP, and Vista, but generally people don't have a problem with that. However what they do have trouble with is something that looks similar, but does something completely different. A good example here is how in the default GNOME panel configuration, we ship the "make all your windows go away" button in the bottom left. Kind of a bad idea, one that will go away with the shell design.

But in general, I don't think the problem has anything to do with an "uncanny valley". If we're talking about the consumer space, basically people just use the operating system that came with their computer, until it's time to replace the computer. Overcoming this is I think largely a business problem, not a desktop interface problem.

So on the subject of looking like Windows in the context of GNOME, my take is that it is important to look good and be functional, and having a distinct visual identity is important - but - keep in mind:

Given that data, considering that our target market is, like Windows, general purpose computing, it makes a significant amount of sense to consider issues that occur during transition and what the expected target audience needs.

What did I mean by "general purpose computing"? Well, it's a big world. Think of scientists and engineers using Scilab, or all of those fixed-function registers that currently run Windows. OLPC-type projects. Content creators who need to edit video. System administrators and developers (count me as a skeptic of editor as a service).

What about targeted "netbook" operating systems? There is definitely a large number of people who only need a lightweight computer. I think the core desktop should adapt automatically to those kinds of conditions; for example, you should be able to drop bits of GNOME you're not using (say Evolution), and the panel should adjust Ubuntu Netbook Remix style. There's definitely a place for Moblin type specialized interfaces, and as long as they're generally compatible with the general purpose OS. Concretely, if say Skype has to rewrite or do significant work to adapt their app, there's a problem. But regardless, if Moblin achieves its goal of being shipped by hardware vendors on netbook hardware regardless, it'll be a huge step forward.

Now, different people have different visions of where the GNOME Shell should go, and that's healthy and fine. To an extent these different visions can be accomodated by different means. Ideally of course, we fix the problem in the default design. But failing that, it might work as a Firefox-style extension mechanism that we want to add, a separate project that builds upon shared infrastructure, or automatic interface adjustments like the netbook screen size one I mentioned above.

But you can count me as believing that it makes sense to be sure that the apps you use today continue to work, while achieving the goals of making GNOME look nicer and more interactive than two grey bars, and fixing the obvious problems like poor access to your recent files, no application search, etc. Some of this we've done already, but there's a lot more to do. If you're interested and able, it's pretty easy to dive in to the project!

Words to keep in mind

2009-03-19T19:20:11Z

We reject: kings, presidents and voting.
We believe in: rough consensus and running code.

From David D Clark.

Further awesome

2009-02-02T23:17:14Z

So earlier I raved about how Firebug is made of awesome. One of those Free Software projects that just saves you massive amounts of time as a developer, and really raises the quality bar you expect from tools.

There's one other project I should have mentioned earlier in this category, which is Valgrind. I'm sure nearly all Planet Fedora/GNOME developer readers know if it (though I was surprised there were still people not using Firebug), but Valgrind almost makes you feel like if it was a bit smarter it could write the code itself, and you could kick back on the beach and watch it.

But besides praising Firebug and Valgrind, I wanted to link to ANTLR as also raising the Free Software quality bar. Now, probably a lot fewer programmers have the need for a parser generator than need to debug HTML/JS or C, but I have to say - if you need a parser, ANTLR is also made of awesome. It's not just that the parser generator is powerful, documented etc. What definitely takes ANTLR a notch up is that it actually comes with a custom IDE for writing and interactively debugging your grammar. All Free Software, and pretty sexy too (Though sadly the screenshots are on a Mac). I also started using another nice Terrence library, StringTemplate in a project recently, which is what motivated this blog post.

Are there any indispensible tools or libraries that have really impressed you lately?

Not in DOS anymore

2009-01-30T20:02:32Z

I have to say, this app makes quite a jump from their old DOS-based UI. I would have no idea how to use it, but I'm sure it makes sense after you get training. Good to know one fewer company's custom app is not tied to MSDN and Windows anymore, moving on to Free Software. I wish I could make applications look at that good.

And life gets a little better

2009-01-27T17:50:40Z

You know the feeling. You're happily sitting there, coding away at some graphics or other code in C+GObject, and then comes the point where you need to add a signal to your object. But your object doesn't have any signals yet, so you have to go find and copy the boilerplate. Ok, not a big deal, you say to yourself, it only takes a minute or two. Then you notice your signal takes multiple parameters, and thus you need to generate a marshaler.

At that point you go to add one to your foo-marshal.list file, only to realize you don't have one yet! Now you need to copy a chunk Automake boilerplate, and apparently if you want to do it really correctly it involves three times as much boilerplate involving stamp files and other monsters.

It's around this point you're probably thinking that finding medieval torture devices and using them on yourself on live television would be a less painful remunerative occupation than programming. But there is hope - the awesome jdahlin wrote a patch. The problem - it's not in GLib yet, and it's unclear when it will be.

So maybe you don't buy into the the pitch about polyglot applications yet, but the new GObject Introspection release, because it already depends on libffi, contains a slightly tweaked version of jdahlin's patch, known as gi_cclosure_marshal_generic. Depend on introspection, and never deal with marshalers and other torture devices again!

A few releases in brief

2009-01-15T15:42:59Z

DBus 1.2.12 and 1.2.4.4permissive are out; this release has a good number of virtues, among them that it has significantly faster transmission of fixed array types; see the announcement for details.

Guido Günther is now maintaining, and has released a new version of krb5-auth-dialog. Thanks Guido!

From Here To There

2009-01-14T22:01:40Z

From Here To There is a quick introductory tutorial for people interested in building multi-level applications using the GObject stack, and having your own application be split between C and your choice of runtime. This tutorial uses Clutter and JavaScript, as we're using for gnome-shell.

I've been working for a while now on two applications using the system (gnome-shell, and a personal project not yet ready for announcement), and while there is still a fair bit more introspection system work to do, so far I'm pretty happy with how it's worked out for both projects. My personal project is actually a mashup of C for some graphics and system stuff, Java (JGIR) for the core application logic, and Groovy for some scripting and extensions. It's quite polyglot; I'm practicing what I preach.

DBus 1.2.10 and DBus 1.2.4.2permissive

2008-12-19T20:57:08Z

Freedesktop.org vendors, please get the new DBus 1.2.4.2permissive release into your development stream as soon as possible, so DBus service developers and testers can help cooperate on fixing the broken services. Thanks!

Note: On my Fedora 10 system I got a lot of spam due to NetworkManager talking to HAL without this patch - so you likely want to get that one in at the same time.

HotSSH 0.2.6: Now with less reason for your sysadmin to come after you with an axe

2008-12-19T04:11:50Z

HotSSH 0.2.6 is released. It fixes a number of bugs, probably most important is one where we could repeatedly try (and fail) to make a new connection every 3 seconds. System administrators tend to get antsy about stuff in their log files, so if they were threatening to bodily harm etc., well, HotSSH 0.2.6 is the ssh client you were looking for!

If pain exists to teach one a lesson...

2008-12-07T22:08:14Z

...then I feel there must be a lot to learn from this painful bug. So far I've learned to always delay pushes into the Fedora queue, even for security updates. Anyways, apologies for the trouble; this is really an awful bug. We'll probably be turning up cases where developers had relied on the erroneous permission for some time.

Tomorrow

2008-11-05T19:39:20Z

While traveling post-GUADEC in Turkey, I ended up after dinner one night walking next to a man speaking English to his wife, and like most people in a foreign country I was interested to talk to someone of similar culture. It turned out though he was Iranian, now living in Dubai with his American wife. He was a very intelligent person, a businessman of some sort and we had a discussion about world affairs as we walked back to our respective hotels.

He obviously had a broad world view and experience, so it was a good conversation. Of course the presidental run came up, and when I mentioned I supported Obama, he shook his head and I remember he said to me confidently and with some cynicism, "John McCain will be your next president". I had felt so sure that America would warm to this eloquent, charismatic scholar of constitutional law, but at that moment I experienced some lingering doubt which stayed for a week at least.

Not that he's likely to be reading this blog, but I'd just like to say - told you so!

Today

2008-11-05T00:37:08Z

A rare nontechnical blog entry from me today; I have had some technical ones queued up in the back of my mind for a bit, but it was hard to spend today thinking about technology. Or, at least other than as a delivery mechanism for election results.

Before Obama decided to run for president, I read an article about possible presidential contenders which included him. The article linked to this YouTube video of Obama. I was struck by his charisma and, doing a bit more research, his extraordinary intelligence and hopeful message. This guy didn't get into an ivy league school via the old boy network like Bush did. I decided within that hour that if he did run, I would contribute to his campaign, the first time I'd ever really done anything approaching active participation in politics beyond voting.

I have a feeling that's true for a lot of Americans right now. Anyways, I planned to keep this blog short. I just had to write something though - it's an immensely inspiring day today.

finding algorithms

2008-10-07T02:24:54Z

Dear lazyweb, I recently found myself having a set of Unicode strings (in main memory) and the desire to search all of them for a particular prefix (not substring). For bonus points, let's say I want to do it in parallel (seems like an easily parallelizable problem, although at worst you can divide-and-conquer for a given number N of processors). The constraints are that the set of strings can change, but not very often usually. I don't want too large of a hit to compute tables and the like though.

The real question is - how do you find papers (and implementations thereof) for computer science problems like this? My first instinct was to get an ACM subscription, which I did. Their search turns out to be mediocre, and then I discovered Wikipedia has useful pages on these kinds of things. Wikipedia also has the winning feature of linking to quality free software implementations thereof.

On this particular problem, a lot of the literature is around substring matching which isn't what I want, at least not directly. Still looking.

Dear GObject/C library authors

2008-10-06T20:21:12Z

Get ready - it's coming. At the GNOME Summit this weekend we're having a hackfest on introspection. As a programmer working on a GObject library, here's what you need to understand:

Using gtk-doc annotations

Just parsing the C code isn't enough - we sometimes need additional metadata. Here's an example:

/**
 * gtk_list_store_set_column_types: 
 * @store: a #GtkListStore
 * @n_columns:
 * @types: <array,length=n_columns>: List of types
 */
void
gtk_list_store_set_column_types (GtkListStore *list_store,
                                 gint          n_columns,
                                 GType        *types);

There are more examples here. This syntax hasn't really seen much bikeshedding yet, and to be honest it's grown rather organically. So things could change. But the goal is for the annotations to be concise, fit in with gtk-doc, and support a variety of attributes; we don't want to require a totally different IDL format.

Add your library to gir-repository and check it

The current thought on deploying introspection is to have two phases. In the first "unstable" phase, we will also have two separate modules: gobject-introspection and gir-repository. It's unclear yet whether the former will remain separate from glib or not in the long term, but expect it to exist separately for now. For gir-repository, the long term plan is to integrate everything into the relevant modules themselves, but for the next 6 months or so while we're finalizing bits, we will keep annotations and code to invoke the scanner inside this centralized module.

So for now, you can add your library (if it isn't there already) to gir-repository by filing a patch in Bugzilla (glib/introspection), or pastebin on irc.gimp.org:#introspection. After you have your library successfully parsed by the scanner, the first task is to inspect the generated .gir file. This XML file describes the parsed API. Try searching in particular for any APIs you think are tricky.

Try out your library in a binding

After inspecting the .gir file, you can try out your API from one of the bindings such as PyBank or JGIR, with more coming. We expect to do some PyBank hacking in particular at the summit, and hopefully get the Spidermonkey and Mono bindings further along. There is a lot to do for all the bindings, but I hope that introspection can be a strong focus point for collaboration between the bindings.

Writing bindable APIs

I've started a wiki page about how you can keep your C code easily bindable. More content appreciated! This page will likely be a bit fluid as we determine both what is supported in the introspection core, and how its concepts map to languages.

That's it for now - remember if you're in the Boston to come to the summit!

Cambridge (US), 6pm today

2008-09-29T16:53:23Z

If you're interested in programming languages and you're in Cambridge, you should come to this Boston Lispers meeting. The author of Clojure, Rich Hickey, reportedly gave a great talk at the JVM languages summit which hopefully he'll reprise here!

"Linux distribution"

2008-09-18T18:47:02Z

At the plumber's conference right now, just finished watching Arjan and Auke's 5 second boot time talk. Very very impressive talk.

They drove a lot of changes into the entire stack, from how the kernel works to fixing HAL and X.org bugs, filesystem tweaks in order to get to 5 seconds. Of course they cut out some things too - since the netbook targets are mobile single user machines, they don't use GDM, I'm pretty sure they aren't starting CUPS, etc.

But this talk led me to only feel more strongly about something that I've been feeling increasingly more lately - that we have been far too complacent about accepting "Linux distribution" as a concept. This is the idea that you can take the Linux kernel and a variety of tarballs found on the Internet, compile them and put it in some variant of tar, and you have an operating system. It turns out it's not that simple.

To create a compelling system, first, you need to make decisions about how things work and how things fit together. The "Linux distribution" mindset is an excuse for having different vendors make different decisions and we end up sharing very little. We need people like Arjan's team, the Ubuntu team, the Fedora team, the OpenSuSE team to share far more than we do now. I think a lot of vendors ("distributions") tend to have an insular mindset where they think they are the center of the universe and why doesn't everyone just join their project anyways?

Five or six years ago I think there was more of a mindset that Linux and the Free Desktop was going to take over from Windows ("year of the Linux desktop" and all that) and each vendor thought they were going to take over the world and consequently were less interested in collaboration. Personally I don't think we're going to see that sudden takeover any time soon, but at the same time if we do things right there is a lot of opportunity.

It's easy to say distributions are bad of course - far harder to actually collaborate better. How do we do that? Here's an idea:

Share a core OS image built at freedesktop.org

We're not going to unify all the different packaging tools tomorrow. However, there's no reason that the core OS build tools and image (kernel, dbus, HAL, X.org) couldn't be shared. So "distributions" could keep their favorite variant of tar and wget (.deb and apt, rpm and zypper, rpm and yum) for everything outside of the image. In other words you could still do "apt-get install epiphany" or "yum install httpd" whatever other app on top of the image and that would still work in a normal "packaging" way, but the core OS image would be rsync'd outside of that.

Each vendor would still control all of the code - each component of the image could have a "vendor" branch where vendors can add kernel drivers and the like. Image update policy would still be controlled by vendors.

There of of course other things that it's completely stupid to fork like bug trackers and more importantly the bug reports. We need to do a much better job of sharing bugs in the right place - the upstream project.

In a sentence, take projects like freedesktop.org and gnome.org as more than just tarball sources and turn them into real collaboration points where things get tied together, sharing actual infrastructure. It wouldn't be easy but really, we need to stop thinking that it's acceptable to have 5+ major forks of the core OS infrastructure.

How to unbreak Emacs somewhat

2008-08-09T18:17:37Z

I'm back to using Emacs for editing C and Python code for now. There are various reasons for this, but mainly it comes down to the fact that I need an editor and not an IDE; creating projects just to edit a bit of code is too much overhead, at least in the IDEs I have tried. Now, one major problem Emacs has had forever is that people (including me) have implemented new modules for it that "unbreak" various parts, but the maintainer has been very conservative about changing anything.

For this reason, here's what I consider the "minimal unbreak Emacs .emacs" file:

;;; Minimal Unbreak Emacs
; Waste of display space if you can't click on it
(if (not window-system) (menu-bar-mode nil))
; Really.
(iswitchb-mode t)
; Assuming you didn't use Emacs from before when the concept of
; selecting a single region of text interactively was not supported.
(transient-mark-mode t)
; This one is actually fixed in Emacs 22; http://www.emacswiki.org/cgi-bin/wiki/CopyAndPaste
(setq x-select-enable-clipboard t)
; The default for "uniquifying" buffer names sucks
(require 'uniquify)
(setq uniquify-buffer-name-style 'post-forward-angle-brackets)
; Slightly more debatable
(global-set-key (kbd "C-x C-b") 'ibuffer)

(set-scroll-bar-mode 'right)

; Custom keybindings
(global-set-key (kbd "C-c i") 'imenu)

Technically I shouldn't be giving you a C-c prefixed function, but I don't know of another good place for it. Anyways, enjoy. Someday Emacs will come out of the box unbroken; it's happening, just very slowly.