Xfce

Subdomains
 

FOSDEM 2012

  • February 9, 2012
  • Jannis Pohlmann

This year’s FOSDEM is over and I hope that most of us have by now recovered from an exhausting weekend that was first and foremost exciting and a lot of fun! With about 12 people, the Xfce group was—I think—larger than ever before. Add to that a fairly large number of my colleagues from Codethink, into which I bumped at the beer event and FOSDEM itself from time to time. Despite mostly staying with Xfce, I enjoyed knowing and meeting people all over the place.

Unfortunately, some of us—myself included—missed half of the beer event because our trains and planes arrived late. Snow in Brussels, a cold weekend ahead. When we arrived at the Delirium Café at around midnight, I was glad to see that all the others had already made friends again. Olivier, Stephan, Peter, Nick, Simon, Christoph, everyone was there, some of them sufficiently drunk, I imagine. Although to be be fair, you wouldn’t really notice. Most of us left not to long after that in order to be in a good condition in the morning. Having only caught up half on drinking, Christian, Mike and I ended up staying at the Delirium with a few Codethink colleagues including Sam, Luc and Javier—until they finally kicked us out at around four in the morning.

Food, taxi, 2 1/2 hours of sleep later and we were sitting in the hotel, enjoying a fantastic buffet breakfast. Admittedly, I couldn’t eat that morning, ending the night in the Delirium had lead to quite a strong hangover. After the majority of us had gathered in the hotel lobby, we squeezed ourselves into the 71 bus in two groups and finally arrived at FOSDEM. I do not remember the details of the day, but it was a great mix of talks (including my own one about Tumbler, which I felt was not very special, picture below), chatting and minor hacking (at least on my side; Nick made good progress with the settings editor in the meantime). During the day, Jean-Francois, Jens and Mark joined us and we (or most of us at least) ended the day having food in a Vietnamese restaurant close to the hotel and a beer in the hotel lobby.

Sunday was similar, except that I could finally enjoy the breakfast. Lovely. Unfortunately, we didn’t manage to get everyone together anymore, so our initially large group was now split up into smaller ones for the rest of Sunday. We still managed to have a few technical chats about Xfce that day and made a few decisions (see below). Regards talks, I mostly remember the Wayland Q&A session and a talk about social engineering in free software communities, Most of us left in the afternoon or evening. I met up with Luc, Sam, Javier and a bunch of other people to have food in a very nice restaurant. Got up at six in the morning, walked to the central station, took a plane home from the airport and went back to work in the afternoon. Unlike a few others I seem to have escaped the typical illnesses (cold, broken sleep cycles, general exhaustion) that events like FOSDEM always bring along.

Xfce-Related News — Fresh from FOSDEM

Wayland was big this year. I will spare you the details of how it works. Throughout the weekend, we had various discussions that involved Wayland. While it may take some load of Olivier by eventually making window managers obsolete, there is still a major problem with it: it does not support the XEmbed protocol, and therefor will break pluggable settings dialogs and panel plugins. We have sent mails to the wayland-devel list to find out how they feel about this. For now, I suppose this is all we can do.

Reorganization of the settings dialogs

One thing we decided on Sunday was to reorganize the settings dialogs so that the location of particular types of settings becomes more predictable. This applies to appearance and window manager themeing, and the application keyboard shortcuts and window manager keyboard shortcuts in particular. We will rearrange some of these tabs and merge them so that all related settings are in one place. We will also merge the window manager and window manager tweaks dialogs into one.

Release Schedule for Xfce 4.10

Despite a lack of completed features in Thunar (which are unlikely to get finished before 4.10), there are only a few things that really keep us from releasing Xfce 4.10. We have not decided on a release date, but if things go well, we should be able to roll the first pre-release one month from now, in early March. This would mean that a final release in May or June would be feasible.

Possibility of a hackfest

Meeting up with the team is always great fun. Unfortunately, FOSDEM is a busy event and only lasts two days. Like last year, we discussed the possibility of an Xfce hackfest in the future. I would love to see this idea becoming reality. If half a dozen of the relevant people can make it for at least a couple of days, this could greatly benefit the development of Xfce. Ideally, such a hackfest would span over at least 4-5 days, ideally including a weekend to make it easier to attend for people with jobs. Given a relatively small group, it might even be possible to hold an event like this at someone’s flat. This is definitely something that we will look into soon.

Like every year, FOSDEM 2012 was a great event. And like every year, a few more nicknames have turned into real faces that, unsurprisingly, belong to incredibly friendly human beings! I only wish that we had more time to discuss things face to face and do some serious work on Xfce together. In any case, this calls for another iteration next year. And with that, I shall end this wrap-up.

Final exams, diplom thesis and thunar-volman

  • July 17, 2010
  • Jannis Pohlmann

I guess it’s time for an update.

This week I passed the last of four final exams in computer science and human-computer interaction at my university. Not only am I pleased that nine months of learning are over; I am also blessed with excellent grades. And while my understand of good grades is similar to that of money (nice to have it but nothing to focus on and/or brag with), I have to admit that this time I’m at least a little proud of myself. Five years at the university are slowly coming to an end, the first friends are leaving town and it will soon be time to take the next big step in life.

I cannot leave this city before writing another thesis, however. Thus, I am currently looking for a Diplom thesis at the university or at companies related to open source technologies. If you happen work for such a company with interesting thesis ideas or opportunities, please let me know. The thesis is supposed to take about 6 months, ideally starting early in September. After that it’s time to pack my stuff and look for an employer. I’m hoping for a position in open source software development. Areas I’m particularly interested in include Linux, mobile computing, desktop-related technologies as well as renewable energy, environment protection and open government. I’m here to make a difference.

On to something else. A few weeks ago I was offered sponsoring in order to work on thunar-volman for a few days. I accepted the offer, so for the entire next week from 2010-07-19 to 2010-07-26 (including the weekend) I’ll do some sponsored work on porting Thunar and thunar-volman to udev and GIO! The goal is to finish all major features (storage devices, cameras etc.).

Yesterday I did some warm-up hacking on tumbler to verify that if I’m still up to the task. The results: a new ffmpegthumbnailer-based video thumbnailer plugin (written by Lionel Le Folgoc), a new PDF/PostScript thumbnailer plugin based on poppler-glib and a new tumbler release (0.1.2). The master branch contains another commit adding arbitrary URI support to the PDF/PostScript thumbnailer but for that you’ll have to wait until the next release.

That’s it for now, I’ll be a lot more active next week. Take care everyone!

News From Busyland

  • November 25, 2009
  • Jannis Pohlmann

This is just a short heads up concerning Tumbler. I just merged Philip’s last critical commit to complete support for specialized thumbnailer services into master. We’ll have to give this some testing but I’m quite optimistic that we’ll be able to release 0.1.0 this weekend or next week. A new release of Thunar will follow shortly after that in preparation for 1.2 (to be released along with Xfce 4.8), supporting virtual and remote file systems based on GIO.

I’ve been pretty occupied lately. Aside from learning for my final university exams I finished my short thesis on porting Thunar to GIO. I already got the very positive results back and I’m going to publish the official version of the thesis soon. Unfortunately, being busy has started to cause not-so-positive developments as well. I haven’t had much time to hack on anything lately and my attendence of FOSDEM 2010 is uncertain. I might still go but I failed to organize anything related to Xfce this year, leaving us without a devroom and talks. So it’d be more like a private meetup rather than an organized team trip with the goal to represent Xfce.

Another consequence of me being busy is that Xfce 4.8 might include less features than planned, at least with regards to the ones I had in mind. For now let’s just hope that I’ll find a little more time for hacking the next months. It doesn’t look too well right now but who knows…

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.