Gnome

One of the things that pisses me off about gweather is that it occasionally hangs and stops updating. It is a bit easier to tell when this has occurred these days, since it is quite obvious something’s wrong if gweather thinks it is night time when it clearly isn’t.

The current code uses gnome-vfs, which isn’t the best choice for this sort of thing. The code is the usual mess you get when turning an algoithm inside out to work through callbacks in C:

1. One function opens the URL with gnome_vfs_async_open().
2. The callback that gets triggered on completion of the open calls gnome_vfs_async_read().
3. The callback that gets triggered on the end of the read checks the status. If it is at the end of the stream, then process the data and close the stream. Otherwise, perform another read (which will loop back to this step).

This logic is repeated 5 times for the different weather data sources. To clean this up, I started looking at libsoup which doesn’t try to be a full file system abstraction, but provides a better API for the kind of things gweather does.

I put together a simple HttpResource class that wraps the relevant parts of libsoup for apps like gweather. It can be used like so:

1. Create an HttpResource instance for the given URI.
2. Connect a handler to the resource’s updated signal.
3. Call the _set_update_interval() method to say how often the resource should be checked.
4. Call the _refresh() method to kick off periodic freshness checks.
5. When new data arrives, the updated signal is emitted.

Since the code is designed for periodic updates, I added some simple caching behaviour. If the server reports that the resource hasn’t been modified, we don’t need to emit the updated signal.

There are a few things that still need doing:

• Some code to keep a SoupSession instance up to date with the proxy configuration settings in GConf.
• Correct handling of the Expires: response header. If we are checking for updates every 30 minutes, but the server says the current weather report is current for the next hour, then we shouldn’t check again til then.
• Support gzip and/or deflate content transfer encoding to reduce bandwidth.

This code should be pretty trivial to integrate into gweather when it is done, and should simplify the logic. I guess it would be useful for other applets too, such as gtik. The current code is available in my Bazaar archive:

baz get http://www.gnome.org/~jamesh/arch/james@jamesh.id.au/http-resource--devel--0

I uploaded a few patches to the pkg-config bugzilla recently, which will hopefully make their way into the next release.

The first is related to bug 3097, which has to do with the broken dependent library elimination code added to 0.17.

The patch adds a Requires.private field to .pc files that contains a list of required packages like Requires currently does, which has the following properties:

• When verifying that a particular package name is available with “pkg-config --exists“, dependencies in both Requires and Requires.private are checked.
• When running “pkg-config --cflags“, flags from dependencies in Requires are included.
• When running “pkg-config --libs“, flags from dependencies in Requires are included.
• When running “pkg-config --static --libs“, flags from dependencies in both Requires and Requires.private are included.

The purpose of this is to list dependencies that are not exposed in the API of the library in question while not making users of the library link directly to those dependencies. This means that private dependencies can be upgraded to new incompatible versions without breaking applications that only depend on them indirectly.

This is intended for cases like Cairo, which links to libpng, but doesn’t expose any of the libpng API itself. It is not intended for dependencies like gtk+ depending on pango. Of course, this header will cause the .pc file to be incompatible with pkg-config versions prior to 0.16, because those versions don’t tolerate unknown fields.

The other changes are related to the associated autoconf macros:

• Add a PKG_CHECK_EXISTS() macro. This would be similar to PKG_CHECK_MODULES(), except that no variables would be set or substitutes — it would simply run the ACTION-IF-FOUND or ACTION-IF-NOT-FOUND arguments. It is basically a less heavy weight macro for cases where you just want to see if a set of modules is available (bug 3530).
• Get rid of the caching behaviour in PKG_CHECK_MODULES(). Since 0.16, this macro has cached the result of the check based on the variable prefix passed as the first argument. Since pkg-config is quite fast and configure doesn’t store its cache between runs by default, this doesn’t result in any noticable speed improvement and causes build problems for configure scripts that call PKG_CHECK_MODULES multiple times with the same variable name prefix but different package lists (e.g. Eye of Gnome). It seems simplest to just remove the caching, resulting in a simpler and more reliable macro (bug 3550, patch not yet uploaded).

With these changes, hopefully 0.18 will fix up the last few small incompatibilities in the recent releases.

Phillip: your idea about direct client to client clipboard transfers is doable with the current X11 clipboard model:

1. Clipboard owner advertises that it can convert selection to some special target type such as “client-to-client-transfer” or similar.
2. If the pasting client supports client to client transfer, it can check the list of supported targets for the “client-to-client-transfer” target type and request conversion to that target.
3. The clipboard owner returns a string containing details of how to request the data (e.g. hostname/port, or some other scheme that only works for the local host).
4. Pasting application contacts the owner out of band and receives the data.

Yes, this requires modifications to applications in order to work correctly, but so would switching to a new clipboard architecture.

With respect to your no-transfer cut/paste of a movie example, that’s more of a component architecture problem than a clipboard issue. In the context of Bonobo, it can be done provided that the clipboard owner can provide the data as a Bonobo Embeddable, and the pasting application can embed Bonobo Embeddables in its documents:

1. Clipboard owner advertises that it can convert the selection to the target “BONOBO_EMBEDDABLE” (or some other agreed upon targer name).
2. Pasting application requests that the selection be converted to “BONOBO_EMBEDDABLE”, and receives an IOR for the component. Pasting application owns a reference on the component due to the clipboard transfer.
3. Pasting application queryInterface()‘s the component to the Bonobo::ControlFactory interface, and calls the createControl() method to create a control to embed in the document.
4. When it comes time to save the data, the component can be converted to one of the Bonobo::Persist interfaces, and written out.

Of course, there are reasons why people don’t do this (apart from not liking Bonobo), including:

• With the classic X selection model, you don’t need to special case local or remote transfer cases.
• Works in cases where the two applications can only communicate via the X connection (e.g. in the presence of transparent X proxies such as ssh).
• It delegates all the permissions/authentication issues to the X server.

I put up a proposal for implementing anonymous voting for the foundation elections on the wiki. This is based in part on David’s earlier proposal, but simplifies some things based on the discussion on the list and fleshes out the implementation a bit more.

It doesn’t really add to the security of the elections process (doing so would require a stronger form of authentication than “can read a particular email account”), but does anonymise the election results and lets us do things like tell the voter that their completed ballot was malformed on submission.

Phillip: the majority of applications have no cut and paste code in them — they rely on the cut and paste behaviour of the standard widgets. Since the standard widgets like GtkEntry in GTK 2.6 mark their selections as being savable (in fact, any code that calls gtk_clipboard_set_text() will have its selection marked as savable). Most of the remaining cases are ones where you’d want to be selective in what gets saved (e.g. selecting cell ranges in Gnumeric, or regions of images in Gimp), so need to be handled specially anyway.

So if you have a desktop running with GTK 2.6 and have a clipboard manager running, saving of clipboard contents will just work. With similar changes to Qt, Mozilla and OpenOffice you cover pretty much everything the user will come into contact with. For extra points, patch Xt and Xaw, and you’ll get most of the ancient X programs as well.

As for the use of GTK in Anders’ sample clipboard manager, I’m not sure what the problem is here — the important thing is the protocol, which is not GTK specific. I would expect that most desktop environments will provide their own clipboard manager, possibly integrated into some existing desktop component such as gnome-settings-daemon. Then again, they could just use a standalone clipboard manager like Anders’ one if they want.

Lastly, you brought up console programs again. I see this as a red herring for the following reasons:

• There needs to be a single synchronisation point that states who owns the clipboard. This is to ensure that there is at most one owner of the clipboard, and allows paste requests get the right data.
• If you want to interoperate with the X clipboard, you’ll need to allow X to control the clipboard ownership. So if some app is connected to your clipboard daemon, the daemon will need to assert ownership of the X clipboard on behalf of the application.
• If the console app is going to have to be modified to talk to a clipboard server, what is the benefit of making the program depend on your clipboard daemon instead of bypassing it and using Xlib? Conversely, if the console app doesn’t want to talk to an X server, what makes you think it will want to talk to some other clipboard daemon?

The remainder of your points seem to either fall under the subject of standardisation of clipboard formats (not directly related to clipboard managers), or things that can be experimented with using the clipboard manager spec.