Tag: Gnome

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.

Recently Bryan posted about background channels — a system for automatic updating desktop wallpaper. One of the features of the design is a new URI scheme based on the same ideas as webcal://, which I think is a bad idea (as dobey has also pointed out).

The usual reasoning for creating a URI scheme like this go something like this:

1. You want to be able to perform some action when a link in a web page is clicked.
2. The action requires that you know the URI of the link (usually to allow contacting the original server again).
3. When the web browser activates a helper application bound to a MIME type, you just get the path to a saved copy of the resource, which doesn’t satisfy (2).
4. Helper applications for URI types get passed the full URI.

So the solution taken with Apple’s iCal and Bryan’s background channels is to strip the http: off the start of resource’s URI, and replace it with a custom scheme name. This works pretty well for the general case, but causes problems for a few simple use cases that’ll probably turn out to be more common than you think:

• Serving a background channel (or calendar, or whatever) via a protocol other than http. The first alternative protocol you’ll probably run into is https, but there may be other protocols you want to support in the future.
• Any links to a background channel will need to be fully qualified since they use a different scheme. If you move your site, you’ll need to update every page that links to the background channel. If you could use relative URIs in the links, this wouldn’t be the case.

One alternative to the “new URI scheme” solution, that doesn’t suffer from the above problems is to serve a “locator file” from the web server that contains the information needed to request the real information. Even though the helper application will only get the path of a temporary file, the content of the file lets the app connect to the server. This is the approach taken by BitTorrent, and various media players like RealPlayer.

The separate “locator file” can even be omitted by placing the background channel location inside the background channel itself. This is the approach taken for Atom, via a <link rel="self"/> link.

South Africa

I put up my photos from the trip to Cape Town online. Towards the end there are some photos I took while hiking up Table Mountain.

Building Gnome

It looks like with the Gnome 2.10 release, some packages fail to build from CVS if you are using a version of libtool older than 1.5.12. This is due to the way libtool verifies the version strings — in versions prior to 1.5.12, the check to make sure that the interface version numbers were non negative used a shell pattern that only matched numbers up to 3 digits long.

This might have seemd fine when it was coded, since how many libraries actually end up with more than 999 versions without breaking compatibility? However, many Gnome libraries are using noncontiguous interface version numbers so that releases on the stable branch can be assigned numbers guaranteed to be less than the versions released on HEAD.

So many 2.X libraries use X*100 as a base for the interface version number, which means with 2.10 we reach 1000 and things break. With libtool 1.5.12 and newer, the shell patterns have been modified to handle numbers up to 5 digits long, so it shouldn’t cause a problem til we are ready to release Gnome 2.1000 (which will be due for release in about 250 years if the current schedule is maintained).

Mathematics Input

msevior: have you looked at the OpenOffice equation editor? It provides a fairly similar interface to what you’ve put together, with a few differences:

• In OpenOffice, the equation entry window is shown as a pane below the document in the main window.
• The OpenOffice equation entry syntax seems to be “TeX without the backslashes”, which is a little less intimidating for new users (although if you already know TeX, it means that there is more to learn).
• Editing isn’t completely one way. If you click on the parts of the equation in the top pane, it will move the cursor to the corresponding position in the bottom pane. I don’t know how easy this would be with itex2mml, since I guess the transformation is one-way.

I agree with you that this style of input is a lot more usable than the Microsoft equation editor for people who understand Mathematics and need to enter a lot of it. The MS editor seems to be optimised for transcribing an equation from some other source, where you know exactly what it will look like from the start. In contrast, the text interface makes it as easy to rearrange an equation as it is to rearrange the rest of the text in the document.

One of the changes in the Gnome 2.9 development series is the removal of most of the Bonobo code from Nautilus, which results in a speed boost due to lower complexity and less IPC overhead. This had the effect of breaking existing bonobo based context menus, property pages and views. The first two can be converted to the Nautilus extension interface, but the second has no equivalent in the new code (partly because Nautilus is concentrating on being a file manager these days rather than a universal component shell like it was in the early days).

Two of the casualties of the change were gnome-control-center‘s font and theme code, and nautilus-media. Since I wrote the font browser code in gnome-control-center, I updated it to work again. It isn’t clear whether nautilus-media will be updated, since the view was a major component of it, and most of the remaining functionality is provided by totem.

Context Menus

If you are looking at updating a Nautilus context menu to use the new extension interface, fontilus-context-menu.c is a pretty good example to model your code on.

One of the big differences is the way Nautilus extensions are loaded compared to the old context menu API. With the old API, you would provide a Bonobo component and set a number of properties in the bonobo-activation server file listing a menu label, the list of mime types the context menu applies to, what URI schemes it supports and whether it supports multiple files. Nautilus could then do a single bonobo-activation query to find out what context menu items correspond to the current selection, and add them to the menu. If the user selected one of the items, the corresponding component would be activated, and an event sent to its Bonobo::EventListener interface.

In contrast, Nautilus extensions are initialised on Nautilus startup. They indicate that they provide context menu items by implementing the NautilusMenuProvider interface. When the user brings up the context menu, the get_file_items method will be called on all extensions that implement that interface. A list of NautilusFileInfo objects is passed in, and the method returns a list of NautilusMenuItem objects. Also, Nautilus extensions are run in-process while Bonobo components could be written for in-process or out of process use.

One of the benefits of this system is the added control of when to display a menu item, and what to use as the label. If you want to only display your context menu item when 42 text/html files and one image/png file are selected you can. However it does mean that each new extension causes some code to be run before popping up a context menu. I have no idea how this compares time wise to the time taken for the previous bonobo-activation query though.

Property Pages

The interface for property pages is quite similar to the context menu interface. As with context menus, you have an imperative NautilusPropertyPageProvider::get_pages interface rather than a declaritive interface based on activation properties. This has the benefit that you can simply not provide the page when the properties in question are not available for the file (with the old setup, you’d end up providing a properties page stating that there is nothing to display).

The other interesting parts of the extension interface is the NautilusInfoProvider interface that lets you attach extra information to files, such as extra emblems or custom attributes, and NautilusColumnProvider, which lets you provide additional columns for the list view that map to custom file attributes. One example of this is nautilus-vcs, which can show revision numbers for files in CVS working copies and adds emblems indicating the file state.

Of course, there are downsides to the extension interface too — since extensions are always in process, they can crash Nautilus or leak memory. However, it was already possible for Bonobo based extensions to do this if they were designed as in-process components and badly written …

Another issue is that language bindings might find it more difficult to support the extension interface where the language runtime would have to cooperate with Nautilus, compared to out of process Bonobo components where they have more control. I guess we’ll see what happens.

Drive Mount Applet

The new drive mount applet is now checked into the HEAD branch of gnome-applets, so will be in Gnome 2.10. There are a few things left to do, such as making it possible to open the file manager as well as unmounting/ejecting it. I did up a screenshot showing what it looks like as an applet.

Libtool

Finally managed to reproduce a particular libtool bug that people have reported on and off. It does show why some people decide that .la files are evil, since it doesn’t occur when people delete those files …

A reduced test case can be found here. The problem occurs when you have multiple copies of a library in your linker library search path with associated .la files. In the test case, there are the following libraries:

• libfoo.so and libfoo.la in the directory /A. This is the library we want to link to.
• libfoo.so and libfoo.la in the directory /B. We don’t want to link to this one, because it is old.
• libbar.so and libbar.la in the directory /B.

Let’s say I then try to link an app that needs libbar and the new version of libfoo, and happen to use the following link line:

libtool --mode=link gcc -o main main.c -lbar -L/A -L/B -lfoo

In the absense of libtool, this would result in us linking against /B/libbar.so and /A/libfoo.so (since /A comes before /B in the search path).

However, libtool ends up doing something quite different. When it sees -lbar, it notices that there is a libbar.la in /B, expands that argument to the full path name of the actual library (/B/libbar.so), and prepends /B to the library search path. This means that when it gets round to processing -lfoo, it finds /B/libfoo.la instead of /A/libfoo.la, and links to the wrong library.

If this sounds like an obscure bug, note that it also happens if we replace /B with /usr/lib. In this case, we don’t even need the -L/usr/lib argument. So the following command results in linking with /usr/lib/libfoo.so instead of /A/libfoo.so:

libtool --mode=link gcc -o main main.c -lbar -L/A -lfoo

This sort of situation is quite common when trying to build some software into a separate prefix that is also provided by the OS, when you are relying on a few libraries installed in /usr/lib with .la files.

After putting together the test case I tested it out in the latest development release (1.9f), and it appears that the problem has been fixed. Given that the libtool developers are so close to a 2.0 release, I don’t know whether they would bother putting out another 1.5.x release to fix the problem.

So if you do run into the problem, some possible solutions are:

1. Upgrade to libtool-1.9f. I’m not sure how good an idea this is if you are producing tarballs, since they will be packaged with the development release too.
2. Remove all the .la files in /usr/lib. Some distributors seem to take this route (eg. Ximian/Novell and Red Hat).