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

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!

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).

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

 Update:  Now, that’s a coincidence

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!

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.

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

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.

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.

• 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).