Iocane powder

History Meme

Dr. Vollmer’s Cut:

$ history | awk ‘{a[$2]++}END{for(i in a){print a[i] ” ” i}}’ | sort -rn | head
1 emacs

Joining LiTL

Let’s play by the rules:

Who? Havoc and some other guys. And myself. And some other people without a blog (hello jobi).

What? I’m joining LiTL.

Where? Ye Olde London Town.

When? Next week, actually.

Why? To do The Right Thing. Or maybe it was the other way around? For the details you’ll have to wait, but I hope it’ll be worth it; or better yet, you could join the company

P.S: ¡Feliz Día!

Epiphany ♥ WebKit

When I said a few weeks ago that an important announcement would be made about the future of Epiphany some people told me it was really obvious what was coming. Seeing the reaction of some to the now public announcement, it seems there’s still some room for disbelief. Maybe the date didn’t help too much, but hey, the whole point of April the 1st is to make you doubt. If all the news are obviously false it’s not really that much fun.

So, yes:

• Starting from now Epiphany trunk is WebKit only, and we’ll slowly get rid of the abstraction layer.
• We aim to release an usable browser for 2.24, but if we can’t make it the 2.22 branch will be released instead. The 2.22 branch will be maintained as long as it’s needed.
• We have started (thanks Diego!) a TODO list for the WebKit backend. I’ll try to work more on this in the coming days.
• Help, as usual, is welcome!

I should have blogged about this before, but I spent the whole week abroad working on some world domination stuff. Should blog about that soon too… (guys, nudge nudge, wake up).

Leaving Nokia

I’ll be leaving Nokia by the end of next. It’s been a sometimes fun, sometimes strange ride, but it’s time to move on to new and bigger (or maybe not so big?) challenges.

Long live to the three-letter toolkit team! (fer, mdk, tko, luc, xan).

 Update:  Now, that’s a coincidence

Advancements in GTK+-flavored Web Engines

Already back from the Berlin GTK+ Hackfest (managed to not blog even once from there, a bit lame). All the awesomeness that happened has been covered by our fantastic hackers, so I’ll focus an what happened in the ”Web Room”, where hacking on webkit/gtk+ and epiphany with tko, alp and chpe went on all week long.

We did some great advancements that week: we landed the pango font backend, the soup http backend, more progress on the plugin patch (first time I personally see youtube working on webkit/gtk), plans for glib-based unicode management, better windows support for the GTK+ port, a long nice chat with Company about native flash integration with swfdec… we also had some long discusions about the future of Epiphany, and an announcement will be made soon

By the end of the week I decided to get started with the cookies support for the soup backend. When I had a working parser (based on code from the old gtk-webcore, really nice) I decided to contact Dan Winship to talk about my plans. As it usually happens, he already had most of the work done, which he kindly published on a branch (see the bug). Around this point I got hit by libc ‘happenings‘ in Ubuntu, and I spent most of the remaining hackfest time restoring my laptop.

Anyway, already on lovely Finnish soil and while waiting for a movie in a nice cafeteria near Kamppi I fixed some bugs in the libsoup code for cookies, massaged some APIs and added enough glue in WebKit to get this going:

When we finish and commit this and get authentication going (integrated with GNOME Keyring of course!) I think I’ll switch to it as main browser; brave souls from all over are of course welcome to do the same so we can find and fix as many bugs as possible before 2.24. Exciting times ahead!

The Facts in the Case of Mr. Epifanio Navegared

It’s been almost 5 months since the last time I blogged about Epiphany. Attentive followers may have noticed that there hasn’t been any Epiphany releases in the 2.21.x cycle so far; why? I’m glad you ask!

First, the GtkMozEmbed situation was a bit chaotic, and we were not really sure if we’d manage to have trunk in release quality levels by 2.22. Thankfully it seems the embed code will travel in time a bit, which will allow us to not take any drastic meassure. With that sorted out it seems likely know that Epiphany 2.22 will simply support both Gecko 1.8 and 1.9 through the archane but well known art known as “massive #ifdef mess from Hell”.

Second: WebKit! A lot has happened since July:

• The embed code went through a massive refactoring: after quite a few late night hacking sessions, tens of thousands of lines of code touched, the final demise of EphyTab and other events, now it’s much easier to implement in a sane way more complete backends for the browser. As a result of this, many previously missing features of the WebKit port started to work with no need of new APIs on the engine side.
• The Epiphany team has grown a few more wizards: thanks to Cosimo, Cyril, Jan and all the others who have recently helped with code, translations or support.
• WebKit/GTK+ itself is progressing at an astonishing pace: there is a great team, patches and features flow every day, and the Apple engineers are extremely helpful and supportive. There’s always something to do, so come to #webkit and #webkit-gtk on FreeNode an join the party. Go WebKit/GTK+ team!

So: 2.21.4 will be released this weekend. Get it, test it, the WebKit backend works now much better than the code we shipped in 2.20.x. 2.22 will be released, as always, to the day; Mozila backend will be as awesome as usual and hopefully WebKit’s will be more or less dogfood-quality by then. But, 2.24? Man. 2.24 is going to be so awesome Jeff Waugh has promised he will personally go to your house and recite “Dónde están mis pantalones” in 25 languages when you download it. Honest.

The Cyclomatic Horror From Outer Space

I don’t really remember how we got there, but a couple of days ago at the office we ended up talking about the complexity of the codebase we have to deal with. Tommi mentioned the McCabe cyclomatic complexity, “which may be considered a broad measure of soundness and confidence for a program“. According to the Wikipedia article it “directly measures the number of linearly independent paths through a program’s source code“. And there’s this little table, with some pre-defined thresholds:

Well, fair enough. You always have to be a little skeptic about this kind of data, but it might give you some insights about a codebase. So “apt-get install pmccabe”, a tool to “calculate McCabe cyclomatic complexity or non-commented line counts for C and C++ programs“. The man page says:

The obvious application of pmccabe is illustrated by the following which gives a list of the “top ten” most complex functions:

pmccabe *.c | sort -nr | head -10

Sounds like fun! Let’s run it on the gtk/ directory in gtk+… (drum rolls):

Some of the functions are way past the threshold for intractability (and all of them surpass it), and GtkTreeView has 4 of the 10 most complex functions in gtk according to McCabe. I suppose you can extract many lessons from here, but I’ll only give one humble suggestion: we need regression testing for gtk, and we need it yesterday, as it seems that no human being can hack on some parts of gtk without breaking something

N810 and new GTK+/Hildon stack

As others have alread commented, the new tablet is now out. But I’m a software guy, so I’ll talk about the software it runs and let others dissect the hardware.

As Michael says we had to break the API to unfuck cleanup the mess that was our stack until now. This sucks, but I think the benefits are worth it: we now use a slightly modified (but ABI compatible, unlike before) GTK+ 2.10.12, the most egregious crack is gone from Hildon, you have cairo, which is used to render almost all the text you see on the device (but use it with moderation please, it’s not a speed demon yet :)), the theming infrastructure is greatly improved, etc.

The differences in our GTK+ are documented for a change, and there’s an on-going effort to provide a coherent start page for the platform at live.gnome.org/Hildon. Now we need the validation of the community, so please port your apps and write new and excellent free software for Hildon.

GTK+ hacking with Emacs, a small trick

I always like to read others people hacking tips, mostly because I suck a lot at using any tool correctly and I am almost always enlightened by them. Today I’ll try to contribute one small trick to the pool.

I remember the last time I posted something about gtk-look.el, someone asked me: “Why would you want to use that? You know about devhelp right?”. My answer at that point was “It’s faster and I like to get the help inside emacs if it’s possible”. Those are quite valid points on their own, but today I can add more benefits: meet Icicles.

The short description of Icicles is that it adds super-powers to any emacs mini-buffer interaction, among other things. But as always, an example is more instructive than a thousand words.

Say we are merrily hacking on our GTK+ application with GtkTreeView (a classical mistake), and we have, as always, forgotten how to set a treeview in multiple selection mode. No problem, let’s look it up. First, we press C-h C-j , bind in our box to ‘gtk-look’. After that we type ’selection’, as we’re pretty sure the function will contain that name.

Now we press S-TAB, which is Apropos-Complete in Icicles (ie, show me any string that contains my input).

Well, there’s quite a few huh? No problem, let’s narrow the search with M-*, aka Match-Also-Regexp. This will filter our result with everthing than does not match our input, akin to adding an extra grep to end of a pipe in a shell. So, as we are interested in GtkTreeView, we do M-* tree S-TAB:

That’s better! In fact I think I see what I want now, gtk_tree_selection_set_mode. So once more… M-* set_mode S-TAB… There’s only one hit now, so Icicles will select it automatically for us in the mini-buffer:

Enter, and we open it in our browser of choice (w3m for emacs here):

Yep, that was it.

Of course the beauty of this is that we did all that pretty fast and without moving our hands from the keyboard.

There are other cool things here, like the ability to save any completion to a cache to speed up things massively. Say, if you hack on GTK+ you are bound to cycle through its docs many times, so save only the gtk API reference search to a cache file and start your completions from there. See this for more details.

This of course barely scratches the surface, so if you use emacs I recommend you to spend some time in the Icicles wiki, install it and play with it. You won’t be disappointed.

If you see the Buddha on the road, port it to GTK+

Ok, there’s something to play with now for the very early adopters:

• Checkout Epiphany trunk (http://svn.gnome.org/svn/epiphany/trunk/)
• Apply the patch on bug 459333
• Checkout WebKit trunk (http://svn.webkit.org/repository/webkit/trunk)
• Build and install the GTK port:
  • cd WebKit
  • WebKitTools/Scripts/build-webkit –qmakearg=WEBKIT_INC_DIR=$PREFIX/include/WebKit –qmakearg=WEBKIT_LIB_DIR=$PREFIX/lib –gdk
  • cd WebKitBuild/Release && make install
  • For me the path to the pc file was broken and had to fix it in the Makefile, will open a bug tomorrow
• Compile Epiphany with –with-engine=webkit flag
• I didn’t say it would be easy

If everything succeeds you should be able to launch the browser and load URLs from the entry. Beware that the port is very basic, so almost nothing will work. A lot of work is needed both in ephy and webkit, if you want to help come to #epiphany at irc.gnome.org or #webkit at irc.freenode.org.

Some (IMHO) exciting ideas are on the backburner for WebKit-GTK, so stay tuned. The basic summary would be that this could become the really integrated browser GNOME deserves, down to the engine level.

PS: following the tradition of silly hackergotchies someone might want to use this for mine. Photo by the crazy Peruvian (aka Diego).