Quim Gil announces why.

I just realized that the promise of ipv6 will create a demand for good clipboard integration in console applications! Imagine the very long ipv6 addresses that many Unix/Linux admins will have to move from spreadsheets into configuration text files!

Therefore I propose that we start thinking about a libclipboard library. As a pragmatic bridging solution we could easily make a small DBus service that not converts but bridges the target requests to the x11 clipboard owner. This service would just play as a proxy rather than something that collects and harvests x11 clipboard targets (the x11 clipboard supports requesting the owner to convert to a desired format, getting a list of available formats, etc - called targets -).

Meanwhile we could let console applications finally enjoy a decent clipboard that can actually make it possible for a console application to request multiple formats. Sounds better than xterm hacks to me.

Before continuing with reading, do this in your mind:

If you are a religious vim user:

export EDITOR=vim

If you are a religious Emacs user:

export EDITOR="killall -9 vim; emacs"

Examples:

• Select text in Firefox, paste as HTML source in $EDITOR
• Select two columns and twenty rows in a spreadsheet application, and paste as a comma separated list in $EDITOR

Maybe even have an easy to configure filter application that on-the-fly converts just a copy source into a format that the admin wants in his configuration text file. You know how management always delivers things like IP addresses in spreadsheet format (it’s just a silly example, really).

We could also let such a library solve the problem of two applications running on the same computer being displayed on a remote X11 server having to transfer large clipboards over the X11 protocol (over the wire).

I still think PRIMARY and SECONDARY are broken concepts by design. But I also agree that this is subjective (but really, let’s be honest about it, it’s broken. Seriously).

Of course I realize that whether or not I’m right about such a solution only depends on somebody (like me) doing it rather than just blogging about it. I have always been tempted to try to start something. Who knows someday I will?

I have been whining about features that I want in Vala to Jürg. To make up for all the time he lost listening to me I decided to fix two Vala bugs.

The first bug I fixed was using a recursive mutex for lock statements. Code like this will work as expected now:

public class LockMe : GLib.Object { }
public class Executer : GLib.Object {
	LockMe o { get; set; }
	construct { o = new LockMe (); }
	void Internal () {
		lock (o) { }
	}
	public void Method () {
		lock (o) { Internal (); }
	}
}
public class App : GLib.Object {
	static void main (string[] args) {
		Executer e = new Executer ();
		e.Method ();
	}
}

Here’s a gdb session that most GLib programmers will recognize:

Breakpoint 1, 0x08048a87 in executer_Method ()
(gdb) break g_static_rec_mutex_lock
Breakpoint 2 at 0xb7e4d0e6
(gdb) cont
Continuing.
Breakpoint 2, 0xb7e4d0e6 in g_static_rec_mutex_lock ()
   from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0xb7e4d0e6 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
#1  0x08048b04 in executer_Method ()
#2  0x08049046 in app_main ()
#3  0x0804908a in main ()
(gdb) cont
Continuing.
Breakpoint 2, 0xb7e4d0e6 in g_static_rec_mutex_lock ()
   from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0xb7e4d0e6 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
#1  0x08048a6e in executer_Internal ()
#2  0x08048b0f in executer_Method ()
#3  0x08049046 in app_main ()
#4  0x0804908a in main ()
(gdb) cont
Continuing.
Program exited normally.
(gdb) 

The second bug is supporting interfaces for D-Bus services in Vala. It goes like this:

using GLib;
[DBus (name = "org.gnome.TestServer")]
public interface TestServerAPI {
	public abstract int64 ping (string msg);
}
public class TestServer : Object, TestServerAPI {
	int64 counter;
	public int64 ping (string msg) {
		message (msg);
		return counter++;
	}
}
void main () {
	MainLoop loop = new MainLoop (null, false);
	try {
		var conn = DBus.Bus.get (DBus.BusType.SESSION);
		dynamic DBus.Object bus = conn.get_object (
			"org.freedesktop.DBus", "/org/freedesktop/DBus",
			"org.freedesktop.DBus");
		uint request_name_result = bus.RequestName ("org.gnome.TestService", 0);
		if (request_name_result == DBus.RequestNameReply.PRIMARY_OWNER) {
			// start server
			var server = new TestServer ();
			conn.register_object ("/org/gnome/test", server);
			loop.run ();
		} else {  // client
			dynamic DBus.Object test_server_object =
				conn.get_object ("org.gnome.TestService",
					"/org/gnome/test", "org.gnome.TestServer");
			int64 pong = test_server_object.ping ("Hello from Vala");
			message (pong.to_string ());
		}
        } catch (Error foo) { }
}

Yesterday I was invited by a company that is specialised exclusively in bells, automation of bells, tower clocks, chimes and carillons for churches, cathedrals, public buildings, industry and schools.

They want to build a more modern version of their current device. They want it to have a little touch screen for example. The device is used for programming the songs that will come out of the tower. For example if there’s a wedding tomorrow, the technician or the priest himself configures his church’s bells.

And for your information. In the UK they indeed do this manually in most of the churches (usually there’s a community attached to the church for this). Lack of volunteers has created the need to automate this in other parts of Europe.

I’m doing some contract work for another big company so instead of coding the application we decided that I would give their developer a short training.

I tried to explain him how to make a signal in GObject, some Gtk+ things, how to make a GObject, how to use the GMainLoop correctly. I explained the GDK lock, how to use it with g_idle_add_full. The usual stuff.

I think I did succeed in explaining how to use glib-genmarshal, but this seemed to be quite complex to understand according to the developer. Then I thought about Vala! I decided to explain this person, in fifteen minutes, how Vala works. What its purpose is.

When I showed him how to do signals in Vala the developer suddenly grasped almost everything about our damn-complex signals. He immediately made the connection with how C# works with its events. Everything became clear. He’ll probably code most of his stuff in Vala now.

This kinda shows me that our GObject and C fanatics are getting it wrong. If we want vertical application development with GNOME Mobile, we don’t want to explain people how to do this in C. We want to explain them how to do it with Python, with C#, maybe C++ and definitely with Vala too.

I think our documentation and library development efforts are therefore not heading in the most optimized direction. Our C based libraries and their documentation should care more about higher languages being their consumer, than about showing how cool tricks you can do in C. Right now, most people developing libraries are still much more into showing their C skills.

The C tricks in your public .h files are irrelevant for application builders who’ll use your API in a higher programming language. Don’t make your API unusable by requiring the consumer of it to utilize C-isms.

My advise? Write all of your public API in Vala and let it generate the C header file.

In Vala you can define interfaces just like in C# and Java. Interfaces imply that you can have class types that implement one or more such interfaces. Vala does not force you to implement its interfaces in Vala. You can also implement them in good-old GObject C.

Here’s a detailed example how you implement a type that implements two Vala interfaces in GObject/C:

Your application used to be single threaded and is consuming a resource that is not thread-safe. You’re splitting your application up into two or more threads. Both threads want to consume the non-thread-safe resource.

In this GNOME-Live item I explain how to use GThreadPool for this.

It’s a wiki so if you find any discrepancies in the sample and or text, just correct them. I’m subscribed so I’ll review it that way.

The GNOME-Live item is done in a similar way to the item about using asynchronous DBus bindings and the AsyncWorker item.

Summer of code 2008

I’m going to mentor three Summer of Code applications.

• E-mail activity for OLPC by Shikhar Bhushan
• Seahorse integration in Evolution by Zhang Shunchang
• SuperRandom, a predictive listening plugin for Rhythmbox by Charlotte Curtis

One of the Igalians who developed Modest and among many of his Tinymail contributions implemented the libcst implementation for handling certificates in Tinymail, José Dapena Paz, is going to mentor Zhang Shunchang’s application together with me.

Picking up what I left in 2005

I also just picked up AsyncWorker. I made it a little page and with the help of Tinne I improved its API documentation. Perhaps I will do a release someday (I never did, actually). Thing is that I hate the work involved with releasing. Especially since most of our development tools stink.

Note that my super fantastic lovely girlfriend, Tinne, has her own blog now. It contains a bunch of photos of our stay in Durham UK. In a few minutes, she just told me, she will put online a funny photo of me holding a fish bowl filled with cocktail.

While I was gathering some info about a DBus related task that I’m doing at this moment, I wrote down whatever I found about DBus’s glib bindings in tutorial format.

A few other people have done similar things in their blogs. This one explains how to use org.freedesktop.DBus.GLib.Async a little bit too.

If you find any mistakes in the document, it’s a wiki page so please just correct them.

I just released Tinymail’s pre 0.0.9, enjoy!

I noticed that more and more people from several specific cities are visiting Tinymail pages, and I know at least a few companies and organisations who are using Tinymail right now.

My personal opinion on development frameworks is that if they come without documentation, they are worth as much as vaporware.That’s why I started first, at an early stage, with writing the API documentation of Tinymail and then Tinymail’s trac, which holds a collection of examples and on top of the API documentation also explains most of its types and how to use them.

This was not sufficient. I wanted to write a test E-mail client to find the source of bugs in Modest. While I was doing that I decided that this test E-mail client was going to be documentation too. Documentation in the form of source code that itself required documentation.

I started TMut’s trac to deposit that documentation. Yesterday I mentioned that I implemented simple account management in TMut, today this is ~ finished. Here is the documentation about that source code.

New items:

• TMut’s account store
• Account manager
• Account editing

Former items:

• Creating messages
• Select a folder window
• TMut’s menu, its first screen
• Showing the summary of a folder
• The message view component