Anders Carlsson

Clipboard manager in gnome-settings-daemon

So I went ahead and committed code to add a clipboard manager into gnome-settings-daemon. To try it out, you need latest CVS. Then, just:

Start gedit
Type some text and copy it
Quit gedit
Start gedit again and marvel that the text is still available for pasting!

The code should be relatively bug-free but if you encounter any problems, feel free to comment. (Also, note that this only works with applications that support it by calling gtk_clipboard_set_can_store, except for text copying which should work pretty much everywhere)

Havoc

Congratulations Havoc!

Clipboard manager

Philip, if you took the time to read the code you'd see that it's only using the GTK+ mainloop, the other code is plain Xlib. I have a new version that we're gonna upload on The Imedio developer site that just uses Xlib for everything, is that desktop neutral enough for you?

The best thing here would be to build the clipboard saving feature into something like gnome-settings-daemon.

Hardware Hunt

I'm in search for a good USB Wireless Dongle that works under Linux 2.6 with the 12" PowerBook G4. I got the Netgear MA111 one but it turned out to be a new version that used a totally different chipset (which only has a binary x86 driver...)

Anyway, don't hesitate to comment if you know any good dongles!

That will be all...

Hacking

For the last couple of days I've been working on the Noodle project, integrating Evolution and OpenGroupware.org.

The screenshot below shows a calendar entry stored on an OpenGroupware server.

The calendar and addressbook backends have been really straightforward so far, and there are always people to answer my questions in #evolution. Thanks a lot! :)

Answers to some questions

Since my last blog entry I've gotten some questions; here's an attempt to try to answer them:

Why is GnomeProgram horrible?
There are a number of reasons why this is true:

The API. The API is not language binding friendly, it's not even C friendly; it has lots of confusing functions and is plain weird.
The argument parsing. GnomeProgram uses popt, but in a way that is both hard for the application programmer to use, and makes the end result look like something that would make Seth Nickell scream in horror. (Try "nautilus --help" to see for yourself for example)
The implementation. Although this isn't really a problem for the users of the API, it gives the maintainer (me) a really bad headache. There are bugs in GnomeProgram that I've given up on, simply because they are impossible to fix. The GnomeProgram code also contains accessibility initialization code that should be in libgnomeui, but that's impossible because of the design. Ugh!

So how will we do argument parsing in the future? Well, a call to
gtk_init_with_args should be enough, thanks to GOption. (I was going to link to the API documentation here, but gtk.org doesn't seem to be healthy)

Isn't making a flat dependency chain against the idea of code reuse?
No. I am definitely not arguing against code reuse. What I am against is libraries that depend on other libraries for no good reason. For example, libgnome has a config: moniker that was written in order to be able to use GConf as a Bonobo interface. No-one uses this moniker, and no-one ever have. Still, it makes libgnome depend on libbonobo. Is that a good example of code reuse? Not really...
What it all boils down to here is that if I want to use a basic widget such as an about dialog or icon list, I shouldn't be forced to depend on a dozen libraries for no good reason.

When will the gnome libraries be removed for real?
This can't happen before the next binary incompatible release of GNOME, which should be 3.0 or so. As no one knows what GNOME 3.0 will contain or when it will be out, the answer to that question is hard to give.

But isn't GTK+ starting to enforce policy? The file chooser uses the XDG MIME spec for example!
That is true, but just about all of those policies are well-defined XDG standards. There is however not XDG standards for everything yet. If you run KDE and click on an URL, you most likely want it to be opened in Konqueror, not Epiphany. Thus, until we have a good specification for launching default url handlers, GTK+ can't really do anything itself.

I hope this clears some things up.

Handling desktop integration

Motivation

As many of you already know, Jonathan and I are trying to deprecate more and more of the gnome libraries with every new major release of GNOME. Why is that?:

Lack of library goals- Pretty much all of the libraries in the platform have a defined goal. GTK+ is for the user interface, libxml is for XML processing, GConf is for handling configuration. But what is libgnome and libgnomeui for? Right now they're a mix of broken widgets and code that wont' fit elsewhere

Dependencies - The GNOME libraries are pretty high in the dependency chain. If you want to use GnomeIconList, you need to pull in (at least) GConf, libxml, ORBit, libbonobo, libgnome, libbonoboui. We would like a dependency chain that is more flat, especially now that less and less program are using Bonobo at all.
API - A lot of the API in libgnomeui is at least 5(!) years old. We've learned a lot about API design since then.

Desktop integration

One of the most horrible parts of libgnome is GnomeProgram; the code that handles start-up and argument parsing for GNOME programs. This code also sets up the program to be more "integrated" with the rest of GNOME. For example, when your application segfaults you get this nice dialog allowing you to report a bug. When you have accessibility enabled, GnomeProgram calls the necessary hooks for that. All that is done by GnomeProgram.

Also, in GTK+ 2.6 there are more hooks that need to be filled by someone, for example

gtk_about_dialog_set_url_hook

which lets you set a callback function that will be called when an URL is clicked in the new GTK+ about dialog. In GNOME, this would open your default web browser with that link. Remember that GTK+ shouldn't enforce policy about what desktop the user is running. Since we're getting more high-level widgets in GTK+, expect more hooks of this type.

So how would all this be taken care of in a world without GnomeProgram? First of all, what is the difference between a GNOME program and a GTK+ program running in the GNOME desktop environment? Why shouldn't all GTK+ applications get a segfault dialog or be accessible? And how should all this be done?

I'll cover what I think is the answer in my next post. Stay tuned!

For I am the clipboard master

Those of you using emacs might have gotten very frustrated because its clipboard handling sucks. Instead of cutting and pasting using the CLIPBOARD selection, it uses the PRIMARY selection. So very broken...

Anyway, there's an easy way to fix this, just add:
(menu-bar-enable-clipboard) (setq x-select-enable-clipboard t)

to your .emacs and you're set!

In other news, I've been working for Imendio for over a month now. It's been a pleasure; interesting projects and nice co-workers. Thanks Richard and Micke!

Still Alive!

Work
As some of you already know, I joined the Imendians and became one of them. Work starts for real on Monday; I will be working part-time since I'm still in school (for about another year)

Doesn't he look good in a suit?

Hacking
Goption is in glib, and I've added the necessary support for gtk. The trick is to call gtk_init_with_args instead of the old regular gtk_init. gtk_init_with_args takes an array of option entries and will parse them automatically for you. Just like popt! Except that it's not popt (Which is good!)

Life
This weekend I'll go visit my parents at home, since it's the annual market in Torsby. My sister will go there too. I will try to buy a sausage or two.