Club Silencio

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

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!

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

Love gedit, the gedit team

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

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…