better late than never

We finally released a new developement version of gedit that reimplements printing using GTK+ print support. It also includes a custom print preview widget so that we can keep our current UI (print preview embedded in a tab). This means that we do not depend on libgnomeprint and libgnomeprintui anymore… it was about time!

Please test it, test it, test it and report any regression or problem!

Syndicated 2008-01-25 13:32:54 from Club Silencio

GtkSourceView 2.1

Today we released GtkSourceView 2.1, the developement release for 2.2 that will be part of the next GNOME. In this cycle we didn’t have much time to work on it, however over the Christmas break we reimplemented two important features that went missing in the big 2.0 release:

• Marks in the left margin (useful for bookmarks, breakpoints, showing errors etc)
• Printing

This means that we have reached feature parity with the old GtkSourceView 1.

The API however is different from what was there in gtksourceview 1: in particular printing now integrates with GtkPrint instead of using the old and deprecated gnome-print libraries. GtkPrint is a pretty strange beast (due to the fact that a cross platform printing api is quite challenging), but in the end I think we found a pretty elegant API.

We expose a GtkSourcePrintCompositor class that knows how to draw the text view (including syntax highlighting, line numbers, header and footer): when running a GtkPrintOperation to print, you just need to instanciate a compositor for the current text buffer and delegate to it all the pagination and drawing. Pagination, which for long documents can take quite a bit of time, is async which allows to present a progress bar without blocking the UI.

Here is a simple example showing how to use the new printing API:

static gboolean
paginate (GtkPrintOperation        *operation,
	  GtkPrintContext          *context,
	  GtkSourcePrintCompositor *compositor)
{
	if (gtk_source_print_compositor_paginate (compositor, context))
	{
		gint n_pages;

		n_pages = gtk_source_print_compositor_get_n_pages (compositor);
		gtk_print_operation_set_n_pages (operation, n_pages);

		return TRUE;
	}

	return FALSE;
}

draw_page (GtkPrintOperation        *operation,
	   GtkPrintContext          *context,
	   gint                      page_nr,
	   GtkSourcePrintCompositor *compositor)
{
	gtk_source_print_compositor_draw_page (compositor, context, page_nr);
}

static void
end_print (GtkPrintOperation        *operation,
	   GtkPrintContext          *context,
	   GtkSourcePrintCompositor *compositor)
{
	g_object_unref (compositor);
}

static void
print_source_view (GtkSourceView *view)
{
	GtkSourcePrintCompositor *compositor;
	GtkPrintOperation *operation;	

	compositor = gtk_source_print_compositor_new_from_view (view);
	operation = gtk_print_operation_new ();

  	g_signal_connect (operation, "paginate",  G_CALLBACK (paginate), compositor);
	g_signal_connect (operation, "draw-page", G_CALLBACK (draw_page), compositor);
	g_signal_connect (operation, "end-print", G_CALLBACK (end_print), compositor);

	gtk_print_operation_run (operation,
				 GTK_PRINT_OPERATION_ACTION_PRINT_DIALOG,
				 NULL, NULL);

	g_object_unref (operation);
}

Syndicated 2008-01-14 21:00:26 from Club Silencio

Bits & Pieces

Last period was fairly busy and I didn’t get much time to hack on gnome related stuff… I hope to be able to catch up a bit in the next weeks, especially to take care of some great patches that are waiting in bugzilla. <h3>GNOME Talk @ IBM Technical Conference</h3>

Thanks to Fabio Marzocca I was approached by IBM to give a talk about GNOME and ubuntu at a linux technical conference held at their IBM Forum in Segrate. Despite the fact I am not an experienced presenter the talk went farly well, slides are available here. At the meeting I also had the chance to meet Alessandro Rubini of Linux Device Drivers fame. <h3>Google GHOP GtkSourceView themes</h3>

One of the tasks accepted for the Google GHOP program was writing five color schemes for gtksourceview. Will Farrington claimed the task and today delivered five good looking themes. Well done Will!
Check them out at on the wiki page.

I especially like Cobalt, so here is a screenie.

Speaking of Google, this week I also received a Google SoC t-shirt. Thanks Google! <h3>gedit without libgnome</h3>

MIkael Hermansson filed a patch in bugzilla to conditionally disable the libgnome dependency of gedit. As mentioned before I really look forward to disabling libgnome uncoditioally and this is definitely a step in the right direction as we work through the remaining issues.

Syndicated 2007-12-09 16:36:07 from Club Silencio

Delivering the killing blow to libgnome

Getting rid of the libgnome[ui] dependency and of all the legacy stuff that it brings in has been a work in progress for many gnome applications. While replacing some old cruft has been very easy as soon as a proper replacement was put into GTK+ itself, there are a bunch of things for which figuring out what to do is not so clear… Now that we are at the start of the 2.22 cycle I’d like to get some feedback on the status of these things.

As you can probably guess I’ll take gedit as a case, but I think it is pretty much the same for many other applications. In order of importance, libgnome is still needed for:

1. Bug-Buddy integration: gnome-program offers integration with our automated bug reporting infrastructure. This is something we cannot do without. I seem to understand that there has been work to make bug-buddy work as a gtk module or something, but it is absolutely not clear to me what is the current status. Is it already in gnome 2.20? How does it work? Do apps need to do something? Can I just drop gnome-program and things will work?
2. gnome_authentication_manager_init() is another thing that we cannot absolutely avoid, otherwise remote file access will not work. I guess gio/GVFS comes into the picture here, but once again an executive summary on what to do for applications developers would be nice.
3. gnome_accelerators_sync(): this may look pretty trivial (and in fact the function itself is pretty simple and easily reimplementable with gtk calls, however it is not clear to me what kind of magic gnome-program does on initialization to restore the edited shortcuts. Any suggestion is welcome.
4. Displaying the Online Help: as far as I know gnome_help_display() is just a function that spawns yelp with the proper arguments, however it’s a bit silly to manually reimplement that in every app… what are the plans of Yelp/Rarian developers in this area?
5. gnome_icon_lookup() is used to lookup an icon for a given file/mime type. Once again this fairly easily cut&pasted locally however I think we really need to put it somewhere our library stack: it is a common operation for many apps. GTK+ itself reimplements it internally for the file chooser and the recent manager, though unfortunately for some files it gives different results (as far as I recall libgnome does some special casing for some files).
6. gnome-session: I know there is a new implementation of session saving in libegg, but it is not clear if it is still developed and targeted at gtk inclusion.

Unless I am missing some other magic feature that gnome-program provides, that is everything that libgnome[ui] is needed for (I am intentionally leaving out migration from gnome-print to gtk print stuff and from gnome-vfs to gvfs, since they are separate issues).

Will we manage to put the nails in libgnome’s coffin for 2.22?

Syndicated 2007-09-24 09:56:06 from Club Silencio

GtkSourceView 2 API frozen

With yesterday night release of GtkSourceView 1.90.5 (which will likely become 2.0 next week) we consider the API frozen and in the future releases only API additions will happen.

Honestly we hoped to have more early adopters so that we could have more feedback on the API changes, but I can understand how painful it is to track a library that it is a bit of a moving target :)

Anyway, now it’s a good time to start porting your app to GtkSourceView 2 and an even better time to bind it to your favourite language (Python bindings are already available). Why? Because you get a way more accurate syntax highlighting and because you get support for style schemes.

I will not go into the details of the API changes (most of it should be straightforward), my advice is just to be careful with the memory management of the LanguageManager and StyleSchemeManager: unless you want to do advanced stuff like a style scheme editor or use two separate highlighting contexts in the same app, you should probably stick to the singletons provided by GtkSourceView itself.

That said, I should also point out that there are a few feature regressions with respect to GtkSourceView 1 and anyone getting ready to port his app should be aware of that:

• Printing support was dropped: GtkSourceView 1 depended on gnome-print which is now deprecated, this days printing should be done with gtk itself.
• GtkSourceMarkers were dropped: they were pretty much the only API that is not exercised by gedit and we didn’t feel comfortable enough with the API to set it in stone.

We are more than willing to reintroduce these features back in 2.2 (though printing is a bit of a gray area since bits of it really belong to gtk itself), but we need feedback from the apps using the library to get the API right!

Syndicated 2007-09-11 08:07:22 from Club Silencio