Older blog entries for pbor (starting at number 63)

gedit on osx

When blogging about the Windows port, I should also have mentioned the thanks to Jesse, gedit trunk also compiles and runs on OSX. Help with the creation of an installable bundle would be warmly appreciated!

gedit on OSX

gedit on OSX

Syndicated 2008-12-28 13:06:40 from Club Silencio

Late Christmas gift for Windows users

In the last days nacho has been doing great work on gedit to finally get it to compile and work on Windows. Today we reached a milestone producing a first working version of the installer. It is an alpha version and obviously still needs many fixes and polishing (for instance python plugins do not work yet), but hey, if you are used to notepad you can’t complain :-)

Give it a try and let us know.

gedit on windows

gedit on windows

Syndicated 2008-12-25 18:57:40 from Club Silencio

gedit ported to gio/gvfs

In the last months I’ve been pretty busy and time for gedit, gtksourceview and GNOME in general has been particularly small. The lack of posts on this page pretty much reflects that.

When reading discussions about decadence I could not help but feel a bit guilty, especially since gedit user base has never been more healthy: new plugins are released, users partecipate on irc and mailing lists, blog posts  about customizing gedit pop up daily on the interweb.

It seemed inevitable that gedit 2.24 would have been pretty much exactly the same as 2.22, but Jesse came to rescue. He first ported the filebrowser side pane to gio and last week he completed the work by also reworking all the gedit internals (especially remote file loading and saving) to use gio instead of gnome-vfs. As of today I committed that work to svn and I will try to make a tarball release as soon as possible.

Since Jesse was on a roll, he also ported all the dialogs from libglade to gtkbuilder, killing yet another dependency.

Please test it, test it, test it and test it again and then report bugs!

Syndicated 2008-08-13 12:00:31 from Club Silencio

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!

Print Preview screenshot Print Preferences screenshot

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.

GNOME Talk @ IBM Technical Conference

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.

Google GHOP GtkSourceView themes

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.gedit cobalt theme

Speaking of Google, this week I also received a Google SoC t-shirt. Thanks Google!

gedit without libgnome

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

gedit style schemes

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.

Style Scheme selector

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

darktango

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!

Syndicated 2007-08-01 11:00:38 from Club Silencio

gedit call to arms

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.

  1. 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.
  2. 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
  3. 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)
  4. 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
  5. 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.
  6. 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.

Syndicated 2007-06-30 20:18:46 from Club Silencio

54 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!