New logo

New logo, courtesy of Henry Peters.

New gedit logo

As announced by nacho, we have been looking for a new logo for a while. We had many interesting submissions and iterated through a couple of designs, borrowing ideas here and there. Thanks to all those who sent us their work!

Not only the new logo is already committed, but you can even wear it :)

gedit 2.29.5

I just rolled the tarball for the next development release of gedit. This release marks an important milestone, since we completed all the goals we had on our roadmap for 2.30.

In particular this release overhauls the internals of I/O handling in gedit by always using gio for file loading and saving (we only used gio for saving remote files) and by taking advantage of the new data conversion api added by Alex.

For the casual gedit user these changes should be pretty much transparent, since they do not introduce new features except for the ability of forcing different line endings (Window’s CRLF, old MacOS CR and the usual UNIX LF). However since they are affecting one of the most important parts of the gedit codebase we would like to ask anyone running the development version and in particular who uses files with encodings different from UTF-8, to heavily test file loading and saving  and report any problem or regression.

JavaScript in gnome

Being away from home, bored and yet too tired to do something productive, I skimmed through the gnome-shell proposal mail thread on d-d-l and spotted the inevitable debate on the choice of javascript as a scripting language for the shell.

Personally I am not a big fan of js, quite the contrary, but lately I had to use it extensively (though not in gnome related context) and at the end of the day it is a language as any other. I am not saying it would be the one I would have chosen, but once you use it a bit and get to know its idiosyncrasies, you get what you need done and move on with life. After all any programming language sucks, each one in its own special way and some more than others, but they all suck.

Reading in the aforementioned thread the reasons why js was picked I would have been totally satisfied with valid answers like:

  • “It’s my project I and pick whatever language I please”
  • “Some of the more talented and experienced gnome hackers chose it. Trust them”
  • “It is not C++ or perl, so do not complain”

Beside given that javascript

  • has good free implementations
  • is widely used (not only in general, but at this point also by various big gnome projects)

I do not have any major problems with it. After all we have clean and consistent code bases written using GObject C conventions, I do not see why we should not be able to tame js as well.

That said, some of the rationales provided for choosing it in the above mentioned d-d-l thread really really trouble me.

js has no platform libraries, so we can use our own

What kind of reason is that? First of all when you embed another scripting language you are not forced in any way to use its standard libarary as well. Second, having a good standard library (or a large set of third party libraries) is a good thing: I thought we were focusing on implementing good applications instead of reimplementing and maintaining a “gwhatever” library for every problem in the world.

using js will attract web developers

That is plainly naive. First of all I have never hacked on something because it was written in a language, at most I have learned a language because something I wanted to hack on was written in it. Second learning the syntax of a language is nothing compared to learning library API, tools, workflows etc and even if I have not used js in gnome yet, I am pretty sure they differ a lot from what web developers are used to. Last but not least, I’d prefer to attract a single good developer than a hundred people not willing to invest an afternoon in learning a language/api/tool.

London & gedit news

I just got back from a short trip to London, where beside work I also managed to sneak in some sightseeing and enjoy a dinner with Emmanuele and his wife.

In the mean time Jesse – who despite having opened a blogs.gnome.org account, is still slacking when it comes to actually blogging – has been rocking as usual. In the last days he decided to give some much needed attention to the External Tools plugin. As a result all bugs in bugzilla about that plugin are now resolved and new features have been implemented. In particular the plugin now supports language specific tools, which also means that we can ship a larger selection of default tools since they will not clutter your menu as the will appear only when editing a specific kind of files: if you have any good scripts for your favourite language that you think should be included upstream feel free to send them our way.

Beside the work on external tools, we also started to make some other changes that will be part of the next release. We decided to remove the ancient “Open Location” dialog that allowed you to enter an URI: these days you can enter an URI just fine from the standard file chooser and the common opinion among gedit developers was that nobody ever used that dialog. We instead included a Quick Open plugin that allows to quickly open files (or even switch tabs) with very few keypresses:  while you type it looks into different “providers” (currently open files, recent files, current directory, etc) to suggest you the file you are looking for. Since a video is worth thousands words, see for yourself:

gedit quick open

guitar playing on linux

For a change, a post not related to gedit. During the holidays I decided to dust off my electric guitar and have some fun playing. However when I gave up playing some years ago I sold my amplifier, effects and so on and I just kept my Hamer guitar. Since I just want to have some fun playing from time to time, instead of spending lots of money buying all the equipement I just bought a behringer UCG102, a nice small USB device to connect the guitar to the PC.

The device is detected correctly under linux and works great. However when it comes to the software available on linux the situation is not so great… surely not Plug&Play, especially for normal musicians that do not hack the kernel for a living.

First of all there seems to be a total disconnection between the people doing audio on the “desktop” (Pulseaudio, GStreamer, etc) and the applications for musicians, which seems to be mostly tied to the world of Jack. I understand that playing a dvd and professional digital audio recording have different requirements and design tradeoffs, but still, the user experience as of today is pretty bad and it involves manually launching sound daemons and so on. For instance when I try to run pulseadio and jack at the same time as described here, jack hangs.

At the moment, the working setup I have when I want to play, is to kill pulseadio and run jack with qjackctl manually.

Furthermore Jack on its own has its share of problems: leaving alone the UI of qjackctl (read below for even uglier ui issues), my biggest gripe with jack is that it seems to be able to deal with just one device at a time, so I cannot “route” the sound from the usb device to the pc soundcard/speakers/headphones.

Then we get to the applications. What I need the most is some kind of “guitar amplifier emulator” with effects and so on in order to get a nice set of heavy distorsions to play metal, some screaming overdrive to play rock, some elegant chorus to play fusion etc. Ideally this software would expose an “easy” ui where I just can reorder the effects by drag and drop and turn a few knobs to tune my sound.

What I found and which works pretty well is called rakarrack, which is pretty nice and includes some very good preset sounds… however the UI is… how can I say… maybe it’s easier to describe if I show a picture

Rackarrack Main Window

Rakarrack Main Window

I understand that musicians are creative people and that the usual gray UI is boring for them, but isn’t that a bit too much? Also why use fltk when there are nice, widely available, portable and even fancy toolkits that do not look like 1992 and actually take my dpi into account?

Next kind of app I tried are recorders, so far I gave a quick try to jokosher and ardour. Both look really promising. Unfortunately the first at the moment crashes on my system, but the guys in #jokosher have been really helpful and I’ll shortly try it further and report bugs etc; the latter is tad too complicated for me but it looks really professional and advanced. However even if it uses gtk, it suffers from the we-are-too-cool-to-use-the-default-theme sindrome… at least their built in colors are not as bad as rakarrack :)

I know there are a lot guitarists and musicians in gnome and I have been looking at this things just in the last days. Did I miss something obvious?  Are there any beautiful apps I have not yet seen? What do you use daily? Suggestions are more than welcome

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

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

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 released a new development snapshot release.

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!

Posted in General. Comments Off

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!

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);
}
Posted in General. Comments Off