Yesterday night I released new developement versions of GtkSourceView, PyGtkSourceView and gedit. With this release of gedit one of the more important features of gtksourceview 2 will be visible: style schemes support.

As you can see from the screenshot the old Syntax Highlighting preferences and the color buttons to set text and background colors are gone, replaced by the selection of the style scheme. A style scheme takes care of all of the syntax highlighting colors and also allows to set some more customizations (for instance the current line highlighting color). The plan was to have a simple style scheme editor to create and tweak style schemes from the GUI, but at this point it looks unlikely for 2.20, also because figuring out the proper UI is not as trivial as one may first think. If the lack of a GUI to edit colors really bothers you, feedback is welcome, especially with patches attached :)

At least I’ll try to add buttons to install and remove schemes from file in the hope that a good collection of third party schemes will be soon available. By the way, if any of the Gnome Online people want to give it a try at creating a service to install Style Schemes from an online collection I surely will not oppose.

Creating a style scheme is very simple: just create yourtheme.xml and drop it in ~/.local/share/gtksourceview-2.0/styles.

The file format is very simple, as you can see from this quick example I put together, a lowcontrast dark style with tango colors: darktango.xml

It is basically a list of:

<style name="element" foreground="color" background="color"/>

Where element can be one of the builtin elements (like “text” or “bracket-match”) or a syntax element specified in the form “language_id:element_id” and color can be either specified directly as #NNNNN or defined in a palette.

“def:element_id” stands for the default style for those kind of elements, since GtkSourceView tries to map the styles to reasonable defaults. Let’s make an example: if I write “while” in a C file, gtksourceview will try to lookup the c:keyword style, if that is not defined it will try to use def:keyword and if that is not defined either it will use def:statement.

The minimal set of styles you need to define are def:comment, def:constant,def:statement,def:identifier,def:type and def:preprocessor, but obviously for good looking schemes some more tweaking is needed, like defining def:error or distinguishing def:string from def:constant etc. You will also probably need to define some language specific things, especially for things like diff files or xml files that do not easily map to those default styles.

As said above we are really looking forward to see style schemes created by our users, thus we started a wiki page to collect them. Beside we are also looking forward including the best ones in GtkSourceView itself: currently we have the classic style (similar to gvim colors) the Kate style (similar to the Kate editor colors) and a Tango style, which however still needs a bit of tweaking since at least in my opinion it looks “too light”. We would like to include a couple more styles in gtksourceview of which at least one for dark backgrounds, so if you come up with a good theme or improve one of the existing ones (in particular tango.xml) do not esitate to tell us!

Some days ago lucasr sent an interesting mail to desktop-devel-list pointing out that some modules did not yet release a test version for the next GNOME and suggesting that if the reason was lack of manpower the current developers of the module should post a list of potential tasks in order to attrack new developers.

gedit was in the list that Lucas posted, but that was in part due to the fact that we were working on the gtksourceview 2 port and release was blocking on that. That said, lack of time and manpower is a real issue for gedit these days, so as promised to Lucas here is a list of tasks for gedit.

Note: I am restricting the list to the official gedit tarball, since our third party plugins community is more active than ever and new plugins pop up every day. Beside I am trying to list tasks that are a good fit for new developers, of a size big enough to make the challenge interesting, but without requiring an intimate knowledge of all gedit internals.

GtkPrint port: we would really love to dump the gnome-print dependency and use the gtk print support. However this is not a trivial task: among other things we want to keep printing asynchrounous and we want to keep our custom embedded print preview widget. Muntyan, of gtksourceview fame, has good code implementing print and print preview in his project and he’s willing to share it with us, but it needs quite a bit of refactoring to be used in gedit.

Use Gtk 2.12 features: the next version of gtk will have some very interesting features for gedit and we should take advantage of them. In particular:

GtkNotebook should now have all what it is required to replace a good chunk of GeditNotebook

Use the new tooltips API throughout the code and remove GeditTooltips

Add tooltips to some of the treeviews now that is possible (the tags plugin comes to my mind)

GtkRecent has seen some API deprecation and fixes and gedit should be updated

Take advantage of GRegex for things like filename filtering in the filebrowser pane

GtkBuilder (if it will meet our current needs)

probably other stuff I am now forgetting

Enhance the modeline plugin: the modeline plugin is the plugin that allows to set things like tab-indentation etc writing a special line at the top of the file. They should be extended to also allow to specify the language to use for highlighting and I would love to see the plugin extended to also support a .gedit-mode file put in the current dir so that you can drop it in the dir of your project to specify the codestyle to use. Such file should support setting different modes for different languages (e.g. the usual 8-spaces-long tabs for C and four-spaces indent for python)

Refactor DocumentSaver and DocumentLoader: this is a bit difficult since it touches pretty delicate parts of gedit and since it doesn’t led to any visible change, but I’d like to change the Saver and Loader objects to be abstract base classes plus some implementation classes (one for local files, one using gnome-vfs, etc) since this would make our life easier when gvfs will be released or if we want to make gnome-vfs optional

Project Ridley: I’d love to get rid of many of our dependencies and have an almost Gtk only version (GConf would still be there I guess and gnome-vfs is a bit hard to make optional, see point 4). Libgnome(ui) is used for very few things (like session-saving, which has a replacement in libegg). About gnome-print, see point 1 of the list.

Win32 port: ok, this is a bit hard and may in part depend on point 5, but it comes up from time to time so I thought I could mention it

There are probably other things I am forgetting and maybe nud or jessevdk have some more ideas and will blog about them.

There are also gtksourceview tasks, but those are for another time :) for now I’ll limit myself to say that help with new .lang files in gtksourceview 2 for your favourite programming language would be very appreciated.

Should you decide to pick up the challenge and try any of the above tasks, keep in mind the following advices:

communicate: drop by on irc, let us know what you are doing, discuss your implementation strategy: given that the problem we are trying to solve is lack of developer manpower, I’d hate to see resources wasted in duplicated efforts.

be pro-active: unfortunately, given the lack of time, we will not be able to mentor you as I would like, so you’ll have to be able to learn things by yourself and not stop at the first hurdle… If you don’t know C and gtk quite well, maybe this is not the project for you :-)

ask questions: despite what I said in the point above, questions are always a good thing and I’ll try to answer as time permits

be patient: as said lack of time is currently an issue for us, so we will not always be able to review your patches in a timely fashion. Beside, we are also very picky with regard to implementation details, so sometimes it may be a bit frustrating to get a patch ready to be committed, but good code always pays off in the end.

First of all, congratulations to Paolo Maggi, who just became father for the second time… I guess that this will leave him little time to work on gedit, but that is surely a more important “release” :-)

I am distchecking gedit 2.19.1 as I write, this will be the first developement release that features the port to the new version of gtksourceview, so to install it you will need gtksourceview 1.90.1 and pygtksourceview 1.90.1

Casual gedit users will not probably note any substantial changes, but if you use gedit to code or to write latex or for any other syntax highlighted language you will take advantage of the new features. Chances are that you will also spot some regressions in the highlighting of your favourite language, so please help us improve the .lang files since we do not know the details of all the syntaxes we can currently highlight: lang files are shipped in gtksourceview and are located in $PREFIX/share/gtksourceview-2.0/language-specs.

Obviously even if you don’t spot any regression, there are also plenty of improvements that could be made: since most of the lang files have just been converted from the old format, they do not take advantage yet of the new features of gtksourceview. New lang files are also more than welcome.

The gtksourceview upgrade also affects plugins: if you had any plugins using (py)gtksourceview directly, they need to be updated to the new gtksourceview api.

From the UI point of view, the gtksourceview upgrade affects syntax highlighting color configuration: if you ever tried to customize the syntax highlighting colors from the current gedit preference dialog you know how painful that is. You need to set the style seprately for every tag of every language you use… gtksourceview 2 instead supports style scheme files.

At the moment I totally removed the Syntax Highlighting colors configuration page from gedit preference dialog, but we need to put back a way to at least switch style schemes. A style scheme editor would be nice too, but it requires to design a sensible UI… suggestions are welcome. For now you can set the sytle scheme used changing the /apps/gedit-2/preferences/editor/source_style/scheme gconf key and you can add your own style scheme files in $PREFIX/share/gtksourceview-2.0/styles or in ~/.local/share/gtksourceview-2.0/styles.

At the moment just two styles schemes are included in gtksourceview one called ‘gvim‘ (similar to gedit default colors) and one called ‘kate’, similar to kate default colors… I would really love to have at least a dark-background style scheme, a style scheme using the tango palette and an emacs-like style scheme. Please create and share with us your style scheme!

GtkSourceView has been living in a licensing limbo for a long time: we want it to be LGPL - most of the code is - but the original version of which only a bunch of lines remain was GPL.
With GtkSourceView 2 finally arriving (I’ll try to write more about that later, see nud’s blog for now) we felt it was time to bite the bullet and try to get relicensing permission from all the contributors.

If you ever sent a patch to gtksourceview or wrote a .lang file and read this, please get in touch with us.

In fact things have been pretty smooth so far, except for getting in touch with Chris Phelps (chicane on irc), one of the original authors of the first version of gtksourceview, since his email bounces. If you know Chris’ new email address or know any way to get in touch with him please let us know.

Even better, Chris, if you are reading this after googling for your name, please contact us! :-)

By the way, this is my first post from blogs.gnome.org: I’m far from a frequent blogger and advogato always suited my needs, but the new ‘blogo’ is so nice that I couldn’t resist giving it a try. Anyway my entries should still appear on advogato, unless I made some mistakes in the rss configuration.

It’s clear regular blogging it’s not my thing… Oh well. Currently I am in Sardegna for work and I’ll be here for most of the month. This also means no internet out of work hours. If any fellow gnome user/developer in the Cagliari area wants to get in touch for a beer and a chat feel free to send me an email.

gedit

I just released gedit 2.17.5 for the second GNOME 2.17 beta. No major changes in gedit in this release cycle, but a good deal of bugfixes and little improvements. Beside it’s great to see the third party plugins community very active: every day new plugins pop up and not just developer oriented ones, but also for translators, latex users and so on.

There is still a known major crasher bug in the current release of gedit, which is due to the use of mmap. It turns out that mmap is not as beautiful as some depict it: it makes very hard to deal with I/O errors, which are not so rare with CDs, floppies etc. The bugreport now has a patch that seems to work, but it involves catching SIGBUS signal etc and C signals scare me, so I want to double check it before committing it. If any C gurus have advices I am all ears. Long term we should just replace the current document-loader object with one using GIOChannels which also gives us the opportunity to improve encoding conversion. In fact we already have a first cut of such code, but we are not sure that trading a known, fairly rare crasher with an unknown set of bugs this late in the 2.18 cycle is a good idea…

Just a quick note to say that thanks to nud, the gedit-plugins module is back from the dead. It contains a bunch of useful extensions that are not included in the normal gedit tarball. Read nud’s entry for the details…

It’s great to see gedit plugins pop up on planet gnome. I am already addicted to Richard’s devhelp plugin and seeing actual code for a collaboration plugin is awesome: remote editing is something we have talked about more than once in #gedit, but it looked like a fairly large task so we didn’t investigate the details yet. Leveraging Python and Twisted, jdahlin managed to create a first prototype in a handful of lines of code!

Speaking of plugins, Steve and Jesse agreed to maintain the gedit-plugins module which will contain a collection of useful plugins not included in the main gedit package. Inclusion of plugins in that module will be fairly liberal so feel free to get in touch we them if you want your plugin included[¹].

I feel this is a good time to give some visibility to some of the good plugins that people have developed in the last months:

Marcus Leyman developed an awesome FileTree plugin. This is something we really want to include upstream and David Jonas has been working on Leyman’s code to refactor it into a GtkWidget and adding some features to it.

Gábor Fekete has a CTags plugin. He is looking for someone to help him out, so if you are interested…

Frederic Back created a couple of useful plugins , in particular a python class browser

Markus Jonsson has a plugin to export an html file with syntax highlighted code

I saw on planet kde a screenshot showing system information when you click on ‘Computer’. I agree that it is nice to offer the user easy access to that information and the screenshot is definately visually pleasing. However I doubt it’s useful to display all that stuff every time I open the ‘Computer’ folder and some of the items in the screenshot look fairly unrelated (e.g. CPU specs and common folders).

I think that a nicer place to put some of that info is in the Properties page that you get when right clicking on ‘Computer’ icon in nautilus, so yesterday evening I put together a quick hack with the awesome nautilus-python to prototype the idea:

Code is here in case anyone would like to play with it. It sure needs some more ‘bling’ (memory info and pretty icons), also I guess it would be better to fetch some of the info from HAL instead of parsing /proc, but hal-device-monitor shows all ‘unknown’ for the CPU on my system so I haven’t tried to use it.

clubfan has written a new gtksourceview based editor for anjutareusing gedit code. I am really happy to see this work and I’ll try it out soon. All the hard work done in the last months to make the gedit code clean and nicely split in GObjects pays off since apparently reusing it for anjuta has been pretty easy. Obviously all the cut&pasting is a subotimal solution since makes sharing fixes harder, but as a first step I am happy that at least we avoided to reinvent the wheel once again.

I also noticed that every object was renamed to the use the “anjuta” prefix… while in general properly namespacing the code is a good thing I would have preferred if the “gedit” prefix was kept: it would be one less problem when it comes to merging bugfixes. I also suggest to keep a file in cvs with the date of the gedit “snapshot” you used so that you can see more easily what needs updating.

In the future we should really split things in a real library and push some of the bits in lower part of the stack like gtksourceview and gtk itself.

PS: Johannes, the comments are not in spanish, they are in italian and are just a few leftovers from developement discussions we had and that we plan to cleanup as soon as possible :)