01 Nov 2005

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.

Posted in General. Comments Off

12 Oct 2005

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

Posted in General. Comments Off

28 Sep 2005

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

Posted in General. Comments Off

28 Sep 2005

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

Posted in General. Comments Off

26 Sep 2005

gedit gets python plugin support

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!

Posted in General. Comments Off

11 Sep 2005

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

Posted in General. Comments Off

09 Sep 2005

I cannot agree more with what tml said.

In fact to properly do caseless string search/comaprison in utf8 you also need normalization beside casefolding.
GtkSourceView supports caseless search in a TextBuffer, but not without headaches and some corner cases are still not ok. For instance bug 168247 and bug 303239.

This reminds me of Project Ridley: caseless search is something that definately belongs in GtkTextView itself, however it’s not something as simple as cut&pasting a bunch of code from GtkSourceView to GtkTextView: the current implementation of caseless searching works “well enough” for us, but it operates on the whole buffer which is not acceptable for something as widely used as Gtk. Thus the Right Way ™ to do things is to implement incremental utf8 normalization support in glib. If someone tackles that, he’ll be my hero :)

Posted in General. Comments Off

07 Sep 2005

GNOME & gedit

GNOME 2.12 is out! Congratulations to every contributor.
gedit 2.12.0 and gtksourceview 1.4.1 (1.4.0 tarball didn’t include html docs, my fault) are part of the lot and I hope people will enjoy them: no earth shattering new features or changes but a good dose of bugfixes.

Now it seems a great time to start thinking about what will come next! During the the beginning of this release cycle good part of our work was put into a big refactoring (a partial rewrite in fact) of the gedit codebase which can be found on the new_mdi branch of cvs. It has been soon clear that such a big change couldn’t be done (and get widely tested) in time for 2.12 so it was put on hold for during the last months in order to concentrate on 2.12, but it’s now time to resume that work. The branch not only adresses some of the longstanding features requests and bugs [see the wiki page, I'll try to go in detail some other time] but it also offers a much cleaner codebase (say goodbye to bonobo!) which is easier to work on and to learn. If you were considering to work on a gnome app, this is the right time to jump in: there are a ton of things to be done with varying degree of difficulty and we would surely welcome some help.

Of particular note it’s the revived plugin system (we had to break compatibility since we ripped out bonobo): thanks to gobject the new system should be easiliy bindable and we’d love to get help from some of the many python lovers out there to get gedit plugins in python up and running, since we don’t have much experience with it. Python bindings, along side with some documentation and a stronger commitment to backward compatibility, should hopefully grow our plugin ecosystem which is something we are very interested into, since it allows to exapand the text editor to suit the many needs of each of our users without bloating the core application.

cairo

I took a quick look at cairo to learn a bit about this cool new thing and given my total lack of knowledge of graphics I must say that I am impressed with it. The api is really nice and getting to draw a antialiased semitransparent circle on the screen is a great motivator :) As an exercise I tried porting some bits of gnome to cairo: I made a patch to move gnometris from gnome-canvas to cairo and it works pretty well (though blocks for now are just plain colored rectangles) and also ported to cairo gnome-system-monitor’s graphs (the patch is already in cvs HEAD).
If someone is looking for some exercises to experiment with the cairo api, there are other bits in the desktop that could be cairoified, for instance the libwnck pager used in the workspace switcher…

Posted in General. Comments Off

08 Aug 2005

Release galore

Released gedit 2.10.5, gedit 2.11.91 and gtksourceview 1.3.91 on behalf of paolo. Nothing earth shattering, just bugfixes and minor UI changes (say goodbye to the hated Undo limit preference!). The interesting stuff is on the new_mdi cvs branch, but it’s not 2.12 material.

Some other GtkSourceView users, like the MonoDevelop guys, will be happy to know that it finally stopped messing with their key_press_events, so they can override Enter and Tab to provide their specific behavior.

I’m leaving for a week in Rome tomorrow morning and no, I won’t bring my laptop :)

Posted in General. Comments Off

11 Jul 2005

Uni

Exams finally over, and I don’t mean for this summer, I mean for good: I passed the Last one with the capital L. It was about time. Now I’d better resume the work on the thesis.

small hacks that make me happy

JHbuild is a wonderful tool which I use daily. Sometime ago it gained the really useful feature of displaying a nifty notification icon with the state of the build. This morning I realized that one of the things I often end up doing is to look at that notification icon, realize that an error has occurred and then hunt in which workspace and in which terminal the build stopped. A whole ten minutes later I had this simple patch which raises and focuses the right terminal when the notification icon is clicked.
The patch is for zenity (which JHbuild uses for the notification support) and I am not sure if the patch is suitable for inclusion, since maybe raising the terminal isn’t what other users of zenity want… for sure it’s going to stay in my local copy.

Posted in General. Comments Off