Older blog entries for pbor (starting at number 33)

Tim's post is very interesting, but in my opinion should be changed in "Never reject a feature request", which means that every time a feature is requested, it should not be dubbed as "crack", but neither accepted as is: we should try hard to understand which problem and use case drives that request and try to come up with a solution to the underlying problem. The solution may or may not be the exact request proposed by the reporter: often who identifies a problem is not the best suited person to find the solution.

After all it's Linus himself that often says that "the main job of a free software maintainer is to say no"

(Sunday evening, #gedit)

kikidonk: so tomorrow is the big day?
me: yes! after months, tomorrow I am going to merge new_mdi into HEAD
kikidonk: cool!
me: I fixed distcheck errors and I have a test 2.13.0 tarball here... We really want to put a test tarball out in time for gnome 2.13.3. Unless something bad happens, I am going to do the merge tormorrow morning, now I am too tired to deal with last minutes problems. Night.
kikidonk: night

(Monday morning)

me: Hey, fixed the last distcheck problem in the merged tree, I'm going to commit in a bit
...no response...
me: anybody home?
...no response...
me: /me checks connection... Disconnected!

At this point I thoght, "Oh well, no problem. I'll reconnect in some minutes". It's certainly not the first time my adsl line goes down. About an hour later I start to get annoyed and call the help desk and it turns out that the adsl of the whole (small) town is down! Thus defeating also my fallback plan to bring the laptop to the home of one of my friends and do the commit from there.

gedit 2.13.0

Despite the unexpected problems, new_mdi is now merged on HEAD and with gedit 2.13.0 you can taste all the new hotness!
2.13.0 is faster and lighter and features a load of improvements: draggable tabs, vfs saving, new plugins system that allows plugins to be written in python, a new interactive search UI (try ctrl+k) and many other things: see paolo's mail.
What we really need now is a good deal of feedback and testing since no matter how careful we tried to be, it's inevitable that some bugs found their way into the codebase. In particular we need help with things like a11y, multi head, bsd, solaris and in general all the things we have not a chance to test ourselves.
Before we get a load of duplicate reports, let me also note that there are a couple of known regressions that we decided to punt in order to get the tarball into gnome 2.13.3: autosave and the 'shell command' plugin. The first is already being worked on, while the shell plugin is a bit more complicated... we'll try to get to it, but if someone is looking for a fun hack and wants to give it a try... :)
This also reminds me that our code for food bounties are still open until the release of 2.14.0 and apart from bugfixes there are many plugins that would be fun to write.

Today I was tracking down a GtkUIManager warning we get in gedit new_mdi when you have two windows open and you close one

GtkWarning: gtk_container_foreach: assertion `GTK_IS_CONTAINER (container)' failed

so I take a look at uimanager's code and see that it does the unmerging in an idle handler, and the idle handler was being run even after the window was gone. Since GtkUImanager properly cancels the idle when finalized, I said, ok, we forgot to unref the ui_manager in window_finalize!
And in fact we did... I add the unref and guess what: warning is still there. Stick a printf in finalize and discover that window_finalize never runs! Its refcount is bumped to the magical number 7. After a bit of fiddling I discover that the culprit are python plugins and in particular

py_ret = PyObject_CallMethod (object->instance,
                              method,
                              "(N)",
                              pygobject_new (G_OBJECT (window)));

The refcount of GeditWindow in during gedit_window_destroy it's always 7 no matter how many python plugins I load and at the moment, given how python ignorant I am, I have no clue how I am supposed to solve that... Dear Lazyweb, any suggestions?

About a week ago I and ebassi decided to open a #gnome-it channel on irc.gnome.org (gimpnet): for the first days I just invited one by one the italian people I noticed hanging around in #gnome and #gtk+, but now that there is someone in the channel during most of the day, I think it's time to give it more visibility, so...

gnomers italiani (hackers, traduttori, utenti), siete tutti invitati ad unirvi a #gnome-it su irc.gnome.org!

This is because there seems to be an increasing number of italian people involved in gnome, however we lack the flourishing community of gnome-es, gnome-fr and others... the old #gnome-it on freenode looked dead when I tried to join and it.gnome.org is outdated. An irc channel may not be a huge improvement but its a step in the right direction, so feel free to join and say 'ciao'.

Performance Work

Inspired by the recent performance love day and by the awesome work of Luis Menina and Federico about the slowness of 'replace all' in gedit, yesterday evening I decided to give it a look myself.

Federico explained in detail the first big offender (setting the sensitivity of the 'find again' menu item on every match), however once fixed that issue, 'replace all' is still fairly slow, so we need to continue our quest.
Next thing showing up in the profile is the statusbar code: the cursor position on the statusbar is updated every time the cursor moves, but that means that during 'replace all' the statusbar text changes on every match without need!

That said, I didn't feel like hacking on the old gedit codebase: note that these issues do not affect the new_mdi branch in the same way, since we changed our internal search api. The code there is not yet finalized there is no point in optimizing it yet, however these findings are very useful and will teach us to avoid making the same mistakes.

So I looked what was next in the profile... things started to become a bit less evident: if I was a serious person I should have fixed the statusbar issue and remeasured in order to get a better signal to noise ratio, but... ;)
Anyway, I spotted gtk_text_iter_forward_to_line_end taking up a few percents, which looked a bit strange. The first question was: "what has forward_to_line_end to do with search and replace?". It turned out that GtkSourceView uses it to deal with line markers: fair enough.
So the next step was coming up with a simple test case: the easiest thing to do was taking a GtkTextBuffer, put a line of text in it and move an iter to the end of the line in a loop 5000000 times (where 5000000 is the number of iterations that made the test case take about one minute). Such a stupid test case worked surprisingly well: profiling it with the awesome sysprof clearly showed the two major offenders: _gtk_text_line_char_byte_to_offset and gtk_text_iter_backward_chars.
Both functions need to deal with obtaining an offset in bytes given an offset in number of characters (each character may be more than one byte in utf8) and both functions used a loop to calculate it: guess what? glib has a function that can do that for us, called g_utf8_offset_to_pointer. Such a simple change, which is just a code cleanup, makes the test case take 40 seconds instead of 67 (according to /usr/bin/time).
I am sure that things could be optimized further or maybe, even better, we could try to speed up g_utf8_offset_to_pointer since it's used in many other places, but this example shows that you don't need to be a guru to improve things :)

Apropos of performance... I stumbled in this page on apple developers pages which suggests using fts_* functions (see man fts) to traverse file hierarchies: has any of the nautilus/vfs guys ever looked into them?

770

I forgot to mention that I got a Nokia 770 some time ago: the device is awesome, especially the screen, though I have one dead pixel in the bottom right corner :(
Fortunately is only noticeable when playing marbles fullscreen ;)
I played a bit with the device (xterm, ssh and all the various stuff all other people have already talked about). I also installed scratchbox and whipped up a quick port of glightoff: developing with maemo it's easy and fun, the only problem I enocuntered was that the svg graphics didn't work. I need to find some more time to play with it some more.

Automated GUI tests

After the announce of dogtail I played a bit with it and with LDTP. I am far from an expert in testing automation, but I really think that this kind of technology will substantially improve the quality of our releases. For instance I started to collect some test cases ideas for gedit in the hope to have a good regression testing when switching from the aging but very well tested codebase to the new one. With both dogtail and LDTP I was bitten by the fact that the app needs to be launched with the english locale to work, but apart from that both seem to work (the start of a very simple wrapper for writing dogtail tests in gedit can be found here)

However I can't help but feel disappointed by the presence of two projects so similar... I read the FAQ, I read the mailing lists etc: as an independent I'd still prefer to have one and blessed testing system throughout GNOME and just to concentrate on the testcases rather than writing this blog entry. If there are technical differences maybe it would be better to discuss which is the best approach and merge the efforts. Don't get me wrong, competition is often a good thing, but in this case it still leaves a sour RH-vs-Novell taste in my mouth.

gedit status

new_mdi progresses slowly but steadily: asynchronous saving is a bit painful, especially when coupled with closing a modified document, but it's worth the effort. Among other things we now gained recoverable saving errors. We'll soon merge the branch to HEAD in order to get more testing. Nice to see lots of interest for the python plugin api both on the mailing list and in #gedit. Write your python plugin today, it's easy and fun (some examples here). if you need a crackrock idea to get started just ask (vi-like command bar anyone...)

more gobby

Philipp Kern, one of the gobby authors, dropped by in #gedit after my last post. He is a cool guy and we agreed on many things, from one side reimplementing all the text gedit features in gobby sucks and from the other the old gedit codebase wasn't a viable solution when they started working on gobby (limited plugin architecture, no win32 port[1]).

I don't know if we'll have a gobby gedit plugin in the future, given that gobby is looking like a lively and successfull project at the moment, but I can at least dream on :)

What is sure is that the gobby developers made the right choice of factoring out the collaboration functionality in a separate library and they would love to have python bindings for it.

That said, gobby works today and it's a cool program. And don't bug Philipp about missing undo redo, they are working on it :)

[1]: there isn't a win32 port now either, but it would be way more doable, thanks to tml

After reading luis' post I couldn't resist taking a look at the 'competition' and I tried out gobby. I must admit that it is really cool and already works fairly well.

I however can't help but think that reimplementing a full text editor around the functionality is a fair bit of duplicated work and necessarily leads to a lack of polish in many details of a proper text editor (among other things it lacks undo redo, though I am fairly sure that this is due to the difficulty of implementing undo redo in a way compatible with collaborative editing). I really wish to have this kind of functionality done as a gedit plugin. It could reuse gobby's library or even GOCollab if it ever materializes. It would also avoid language wars (gobby is C++) since everybody knows that doing it in python would be a sane choice :)

On the bright side they are using GtkSourceView. By the way, since gobby also run on win32, if its developers or anyone else using gtksourceview on win32 wants to commit the win port upstream and put binary installers on the site, just get in touch with us.

Speaking of python plugins, adding a terminal pane is fourty lines of python (ok, far from a polished terminal, but still...)

Thanks to the heroic efforts of kikidonk, support for writing gedit plugins in python is now in cvs (in the new_mdi branch for now).

I know most of you have vi or emacs keybindings flashed in your brain firmware, but what about giving gedit a try for a few hours and have some fun implementing your favourite text editor feature in python!

Maybe not as rich as google's Summer of Code or as noble as Vim's charity-ware, but paolo just announced gedit's Code for Food, here is his mail copied verbatim:

Hi GNOME lovers, as you may or may not know, a big rework of gedit internals is under way with the goal of fixing various longstanding issues and improving the quality of the whole codebase. You can find more info about this work on http://live.gnome.org/Gedit_2fNewMdi

If you want to see this work to succeed, it is time to put your fingers on the keyboard and help us with this titanic effort.

So, be a gedit lover and take a task from the Love Tasks list on http://live.gnome.org/Gedit_2fNewMdi#LoveTasks

The most proficuous contributor will get two bottles of Barolo (the most esteemed Italian wine, http://www.barolo.net/scoprire/index.asp) or a 3Kg package of Nutella (http://www.nutellausa.com/).

Love gedit, the gedit team