Xfce

Subdomains
 

Using Tumbler in Client Applications

  • October 29, 2009
  • Jannis Pohlmann

Yesterday, Philip briefly wrote about Tumbler, the new D-Bus thumbnailing service that is going to be used on Xfce 4.8 and Maemo 6. Today, I'd like to explain how to use this service in client applications. Depending on the application type, the usage varies a little, so I'll focus on the basics here. I'll discuss some tricks at the end of this post though. What I'm not going to do is to talk about how to connect to D-Bus, how to call methods on D-Bus objects and so on. See the D-Bus tutorial or toolkit-specific documentation for more information about that.

A separate post with information on how to extend the thumbnail service will hopefull follow soon.

The Service Architecture

The thumbnailer specification defines four D-Bus service APIs. For most client applications only two of these are interesting: org.freedesktop.thumbnails.Thumbnailer1 (the thumbnailing service) and org.freedesktop.thumbnails.Cache1 (the thumbnail cache manager). The thumbnailing service can be used to request thumbnails and get feedback on the progress of requests. The cache manager can be used to keep the cache synchronized with the hard drive contents by notifying it when files are deleted, copied or renamed.

Thumbnail Request Workflow

Thumbnail requests include the following information:

  1. An array of URIs for which thumbnails should be generated
  2. An array of MIME types for these URIs (each element corresponding to the URI with the same index in the URI array)
  3. The thumbnail flavor to generate for the URIs (normal is 128x128px, large is 256x256px, ...)
  4. The scheduling mechanism to be used for the request (foreground, background, ...)
  5. An optional handle of a previous request that should now be cancelled

Because the service implementation might vary depending on the system (right now there's only Tumbler, but who knows about the future...) there is no fixed set of thumbnail flavors and schedulers. The specification is supposed to define a standard set of flavors and schedulers that all implementations have to support (like a normal flavor and the scheduler default). The URI schemes and MIME types supported by the thumbnailing service also depend on the implementation and the availability of thumbnailer plugins and applications extendending the thumbnailing service via D-Bus. So, the first thing an application should do is to to determine which flavors, schedulers, URI schemes and MIME types are supported.

Determine flavors, schedulers, URI schemes and MIME types supported by the service

The thumbnailer service provides the methods GetFlavors, GetSchedulers and GetSupported for this. They all return string arrays with supported flavors, schedulers and URI scheme and MIME type pairs. GetSupported is a bit special, as it returns two arrays (one with URI schemes, the other with MIME types). These are to be interpreted as arrays of scheme/type pairs, each pair of which means that files with both the scheme and the MIME type at a certain index are supported. Applications can use this information to avoid requests for unsupported files. Once all this information is collected, we can continue with...

Requesting Thumbnails

Let us assume for a moment that only one thumbnail is needed and that the flavor we want is normal, the scheduler is foreground, the URI is file:///tmp/foo.png and the MIME type obviously is image/png. We can request a thumbnail to be created for this URI by calling the Queue method of ...thumbnails.Thumbnailer1 like this (written in some kind of fantasy language with dynamic D-Bus bindings ;)):

 handle = service.Queue ("file:///tmp/foo.png", "image/png", "normal", "foreground", 0)

As you can see here, requesting thumbnails for more than this one URI is simple: just append one more URI to the first array and one more MIME type to the second array.

If you perhaps need to cancel the request later, remember the handle returned by the service. In complex applications with asynchronous APIs you'll sometimes need to link internal request handle to thumbnailer service handles, so the handle returned by the service is not only useful for canceling requests.

Being Notified About the Progress of a Thumbnail Request

Once you have requested one or more thumbnails, you'll probably want to be notified about the progress of your request. Tumbler will emit D-Bus signals for the following status updates:

  1. Started is emitted together with the request handle as soon as the service starts processing the URIs of the request.
  2. Ready is emitted together with the request handle and an array of URIs whenever the thumbnail for one or more of the URIs of the request were generated and can now be used. The array passed to you contains the source URIs, not the URIs of the thumbnail files.
  3. Error is emitted together with the request handle, an array of URIs, an error message and an error code whenever the generation of a thumbnail for one or more URIs of the request failed.
  4. Finished is emitted together with the request handle once the thumbnail service has finished processing the request. This can happen when all URIs have been looked at or when the request was cancelled.

Please note that there is no guarantee for the Ready and Error signal to be emitted for all URIs of the request if the request is cancelled. So, if you maintain an internal thumbnail state for URIs depending on the thumbnail progress, you'll have to remember which URIs were queued. In any case you're advised to make sure to free up your own resources in case the service dies or D-Bus crashes. This can be achieved using a timeout (which will also be helpful if the service hangs) or by connecting to the destroy signal of the DBusGProxy (or whatever equivalent D-Bus API is used in your application).

Cancelling Requests

If you want to cancel certain requests, all you need to do is to call the Dequeue method of the service and pass the correct request handle to it.

Loading the Thumbnails

Where to look for the actual thumbnail files after they have been generated depends on the platform. If Tumbler is built with the default cache backend (which should be built on normal desktop systems), files are stored according to the thumbnail managing standard. On Maemo, files are stored as JPEGs. Philip might be able to give a more detailed description about how to access them.

Thumbnail Cache Synchronization and Cleanup

Some applications like file managers or image viewers allow users to rename, copy, move or delete files on the disk. Since renaming, copying and moving doesn't affect the contents of a file, you can avoid to regenerate its thumbnail by notifying the thumbnail cache of this change. When a file is deleted the thumbnail is no longer needed, so in order to prevent the cache from being polluted with dead thumbnails, you can notify it as well.

This is what the ...thumbnails.Cache1 service interface is for. It provides the following D-Bus methods for the above scenarios:

  • Copy (string array from_uris, string array to_uris)
  • Move (string array from_uris, string array to_uris) (this one is useful for both moving and renaming)
  • Delete (string array uris)

If you want to clean up the cache in a more general sense by deleting very old thumbnails you can do this via the following method which deletes all thumbnail whose original files have not been modified in a long time and have a certain URI prefix (which may be empty):

  • Cleanup (string uri_prefix, uint64 original_mtime_threshold)

The above should give you an insight into how the thumbnail service can be used in applications. If you have any questions about this, please let me know. Ok, now let's reveal some tricks to perform optimization on the client side.

Tips and Tricks

  • Use asynchronous D-Bus calls in your application to avoid your application to block. A separate worker thread might also be useful.
  • It's wise to cache the arrays returned from GetSupported, GetFlavors and GetSchedulers. A SupportedChanged signal is planned to allow applications to update their cached information when the thumbnailer is extended by additional URI schemes or MIME types at runtime.
  • If your application generates a lot of thumbnail requests, as file managers and picture viewers with gallery support usually do, you'll probably want to reduce the amount of messages being sent over D-Bus. You can do this by grouping individual requests. Often when you use a GtkTreeView or something similar involving stateless cell renderers, the easiest way to generate thumbnail requests is when the cell renderer renders a file icon. If you don't group these individual requests, the system might go nuts. So, to group these requests you could use a worker thread with a wait queue that is flushed (URIs in it are sent to the thumbnail service as a single request) at most every X milliseconds. When the first thumbnail is needed, you start a one-shot timeout handler that is executed after X milliseconds, grouping all URIs added to the wait queue in the meantime. I do this in Thunar and it has proven to work well. It also scales nicely by grouping more efficiently the more thumbnails are needed in the time slot. Heavier user scrolling won't make things worse.

I guess that's it for now. I hope you enjoyed reading this first real post about Tumbler coming from me (which is also pushed to Planet Maemo by the way). Again, if you have any questions, please let me know.

Design of the Thunar Progress Dialog

  • September 14, 2009
  • Jannis Pohlmann

Today, I merged the shared progress dialog into Thunar. I can be seen on vimeo. This evening I started thinking about the waste of space in it. For each copy/move/link/delete/trash operation we have: one icon and two lines of text, followed by another line with a progress bar (with text) and a cancel button. That's not too much and it looks kinda clean. Thunar has always hidden too detailed information from the user, like the size of the files, how many megabytes have already been transfered/deleted or what the MB/s rate is. But still, three lines of widgets for each operation is a waste of space. And the more space we waste for each operation, the earlier we have to add something like scrollbars around the widgets, as can be seen in the video.So I've made a few mockups to test alternatives. But first, let's have a look at how other file managers do it.

Nautilus / Finder

The progress dialog used in Nautilus is almost a 1:1 copy of the OS X Finder progress dialog. It too follows a three-line design with the first line either showing how many files are being transfered (e.g. Copying 2 files to "Desktop") or what files is transfered at the moment (this is what you can see in the screenshot below, which I am shameless linking here from Bob Peers' weblog). The second line contains the progress bar and a cancel button without any text and the third line shows some stats, again shown in the screenshot.

Now, the problems of this dialog are quite obvious (although not everything can be seen in the screenshot). If you're transfering more than one file, it will be almost impossible to figure out which of the progress views corresponds to this operation unless you know exactly how many files you're transfering and/or how large these are in total. Another problem is that the dialog grows and grows with each operation added to it until it finally grows beyond the height of the screen. Last but not least the progress bar and button heights are different, making the dialog look slightly unpolished.

Dolphin

I have to admit, this is a poor comparison. I couldn't find a screenshot of Dolphin's progress dialog on the net and I'm too lazy to install KDE in a virtual machine. Suffice it to say that I'm not a big fan of KDE GUIs in general. I think the KDE folks have a lot of great ideas but as nice as plasma and all that 4.x goodness may be, most of the windows and dialogs are too busy and cluttered for my taste.

Thunar Experiments

The original design can be seen on vimeo.

The first attempt of an improvement is the equivalent to Nautilus and Finder omitting the statistics by replacing them with a simple <time> remaining text on the progress bar. Like the Nautilus dialog it doesn't display the name of the current file when an operation includes multiple files. This is not shown in the screenshot, because that one is just a hard-coded mockup. All in all, this design makes it even more unlikely to find a job with multiple files again at a later point due to the left out stats.

The second mockup appends the number of files involved to the title (e.g. (1 of 2)) and because of that, it can always display the name of the file being transfered at the moment. The downside is that this of course requires the user to read more text.

Ideas and Opinions?

I'm not 100% sure which way to go here. I kinda lean towards the second mockup but since Thunar is designed to have no redundant options/elements in the GUI, I'm wondering whether the (1 of 2) isn't too much already.

What do you think? Any opinions or ideas for improvements? Sketches and descriptions are very welcome!

Xfce 4.8 Release Cycle Information

  • September 13, 2009
  • Jannis Pohlmann
At the end of August, we've entered the development phase for the Xfce 4.8 release cycle. Today, we're hitting dependency freeze and I think this is a good time to inform you about how the cycle will look like and what we're planning to achieve for 4.8.

The final 4.8 release is scheduled for April 12th, 2010, which is in about 8 months. We're trying to stick to a well-defined release policy for the first time. This includes frequent development releases of individual components and, most importantly, a time-based release cycle.

I'm confident that we can meet the schedule you can see below and would like to encourage everyone to participate in the development and continued improvement of Xfce 4.8, be it as a developer, a translator or a generally active member of the Xfce community.

Below you find detailed information about the 4.8 schedule, the release team, dependencies and planned features. This information is also available on the wiki.

Schedule

2009-08-16 - 2009-08-30: Planning phase
2009-08-31 - 2009-09-13: Extended planning phase
             2009-09-13: Dependency freeze

2009-08-31 - 2010-01-31: Development phase
2010-02-01 - 2010-04-12: Release phase

             2010-02-01: Xfce 4.8pre1 release / Feature freeze
             2010-03-01: Xfce 4.8pre2 release / String freeze
             2010-03-29: Xfce 4.8pre3 release / Code freeze

             2010-04-12: Xfce 4.8 final release

Release Team

   Release Manager: Jannis Pohlmann
       QA Official: Stephan Arts
Release Assistants: Jérôme Guelfucci
                    Ali Abdallah
                    Yves-Alexis Perez
                    Robby Workman
                    Vincent Tunru

You can read up on the roles of these people on this page if you feel like you need to contact one of them because there's something going wrong with the development or release process.

Dependencies

Xfce 4.8 will depend on the following libraries and applications:

  • cairo >= 1.0.0
  • dbus-1 >= 1.0.0
  • dbus-glib-1 >= 0.73
  • gdk-pixbuf-2.0 >= 2.14.0
  • gio-2.0 >= 2.18.0
  • glib-2.0 >= 2.18.0
  • gmodule-2.0 >= 2.18.0
  • gobject-2.0 >= 2.18.0
  • gthread-2.0 >= 2.18.0
  • gtk+-2.0 >= 2.14.0
  • libpng12 >= 1.2.0
  • libwnck-1.0 >= 2.22
  • x11 >= 1.1.0

The following dependencies are still left open:

  • garcon-1 (no release yet, but used in different places)
  • tumbler (no release yet, but used in different places)
  • sphinx (for documentation)

Planned Features

In the following, we give you an overview of the features we are planning to implement for 4.8. Please note that due to the voluntary nature of the Xfce development, none of features are guaranteed to make it into the final release. This feature list may also not be complete as we might be able to implement even more during the cycle. This list is meant to give you an insight in what we're up to and what you might be able to expect in 8 months.

You can find a (hopefully) always up to date list on the wiki page. Each of the pages linked there contains more detailed information about the features, their implementation status and sometimes also who has taken the responsibility to work on them.

We welcome people to help in achieving these goals. All of our repositories are now managed using git (on http://git.xfce.org/) so it's easy to clone them and contribute code to Xfce.

exo

  • Remove deprecated APIs and rename library to exo-1
  • Add GIO module for URI handling to support gtk_show_uri()

libxfce4ui

  • Port all Xfce core components to libxfce4ui instead of libxfcegui4
  • Object-oriented session client
  • GtkBuilder support for e.g. XfceTitledDialog

thunar

  • Finish the migration to GIO/GVfs. Among other features, this will give us network browsing (windows shares, SSH, FTP etc.).
  • Implement our own volume monitoring backend for GIO (based on HAL or DeviceKit-disks)
  • Update thunar-volman to work with this volume monitoring backend and port it to xfconf
  • Integration of remote locations in the side pane
  • Improve integration of tumbler for thumbnailing
  • Port all ThunarVFS thumbnailers to tumbler, write backwards-compatible tumbler plugin for thunar-thumbnailers
  • Use a single progress dialog, grouping all file operations
  • Extend the D-Bus interface so that e.g. xfdesktop can re-use the file properties dialog
  • Startup notification support in the custom actions plugin

xfce4-appfinder

  • Drop libxfce4menu and migrate to garcon
  • Improve keyboard navigation
  • Use startup notification when spawning applications
  • Perhaps implement an extension API, so that xfce4-appfinder can act as a replacement for xfrun4 in the future.

xfce4-panel

  • Finish the completely rewritten panel. This adds a lot of neat features and revamped dialogs. Amongst other things:
  • Introduce an xfconf API for plugins
  • Add an improved launcher plugin based on GIO, garcon and exo-desktop-item-edit
  • Improved transparency support
  • Better panel placement and multi-head support

xfce4-settings

  • Netbook-friendly dialogs
  • Improve keyboard shortcuts (seem to cause a lot of problems)
  • Improve display and pointer settings dialogs
  • Add a clipboard manager daemon
  • Finish/fix the settings editor

xfdesktop

  • Use GIO for the icon view
  • Use garcon for the menu instead of libxfce4menu
  • Improve icon view drawing routines
  • Proper keyboard handling for the icon view
  • Free icon positioning
  • Allow right-click menus to be arranged differently

I think that's it. I hope you enjoy Xfce and are looking forward to the 4.8 release together with us!

Long Overdue Update

  • September 7, 2009
  • Jannis Pohlmann

I haven't posted anything in a while, but I'm not complaining. The last month I've been mostly busy pretending to be busy. Ok, to be honest, that's not entirely true. Over at Xfce, we have achieved a lot in August:

  • We've moved all Xfce repositories (including the goodies) over to Git. Kudos to Brian for doing most of the work.
  • All Xfce translation updates are now submitted via Transifex. Thanks to the Transifex developers for all the support and for being such a friendly bunch. It amazes me that Dimitris, the founder of Indifex, is also active on our translations mailing list to support people!
  • The migration of the Thunar core to GIO is complete and has been merged into the main development branch. The overall delta was 2.9MB, although admittedly, a big part of that is due to the removal of ThunarVFS, so I can only take credit for about 16,000 of the 24,335 insertions and 6,000 of the 41,356 deletions.
  • We've kicked off the Xfce 4.8 development cycle on August 16th. The schedule and all other details are available on the wiki. Xfce 4.8 is scheduled for April 12th, 2010. Expect development releases of the various core components soon!

Other things I've been planning to blog about but didn't have the time to:

  • Samuel is still busy setting up Buildbot. With less time than he had hoped for at hands this might still take a while.
  • I was provided with a free Linutop 2 in June. I'd like to thank the Linutop company again for this gift! So far, I've only found the time to give it a few test boots but I'm planning to set it up as a Xfce test machine soon. Its limited hardware makes it much better platform than my rather powerful laptop and/or virtual machines for testing the speed and memory demand of Xfce.
  • My thesis is progressing slowly. I think I have at least 3/4 finished now. I'll keep you posted about the result. I'm hoping to kick off the six month learning phase for my final exams before October because a friend of mine is already waiting for me. ;)

Appfinder Ideas

  • July 9, 2009
  • Jannis Pohlmann

I've switched to using xfce4-appfinder as a replacement for xfrun4 recently. It's a pretty nice experience overall, even though I'm missing the ability to launch arbitrary commands like I could with xfrun4. So today I had an idea on how we could improve this: all we need is a custom tree model and a plugin infrastructure to allow plugins to be written as appfinder item providers. They could provide any kind of actions depending on the text typed in by the user. Here are two example mockups:

Implementing this should be relatively easy with a bit of experience in GTK+ and GLib. It's not as powerful as GNOME Do but it's also much more simple ... and useful, at least as far as I'm concerned.

Anyone up for the task? Maybe this could be one of the projects for next year's GSoC, should we decide to apply.

Preview: Browsing SFTP with Thunar

  • June 16, 2009
  • Jannis Pohlmann

It feels like I'm finally getting somewhere. My GIO migration branch of Thunar now generates thumbnails using the D-Bus service provided by Tumbler (which is still in development but almost ready for a release). It has no references to ThunarVFS anymore, except for one function required by Thunarx, the Thunar extension library. The next step will be to prepare thunarx-2 with a ThunarVFS-free API. All plugins shipped with Thunar itself need to be updated. ThunarVFS will be moved out of the Thunar tarball and into its own, so that applications depending on it will still work. And then we only need to fork the HAL based volume monitor from GVfs and of course thunar-volman needs to be rewritten on top of GIO ...

Anyway, just a few moments ago, I did something I thought is worth sharing: I browsed one of our servers remotely over SFTP! Mounting still needs to be done from the terminal but after that, you can simply type in the SSH or SFTP URI and it will display its contents. Thumbnails are generated over D-Bus. Here's a screenshot:

Update

Thunar can now mount remote URIs on demand:

FTP browsing also works: