Xfce 4.8pre3 released!
Xfce 4.8pre3 is now available for download.
It includes the following releases of Xfce core components:
exo 0.5.6 gtk-xfce-engine 2.7.0 libxfce4ui 4.7.6 libxfce4util 4.7.5 libxfcegui4 4.7.0 thunar 1.1.6 thunar-vfs 1.1.1 xfce-utils 4.7.4 xfce4-appfinder 4.7.2 xfce4-dev-tools 4.7.4 xfce4-panel 4.7.7 xfce4-session 4.7.3 xfce4-settings 4.7.7 xfconf 4.7.5 xfdesktop 4.7.5 xfwm4 4.7.4
Release tarballs can be retrieved from the following mirrors (please note that it may take a few hours for the mirrors to catch up):
http://archive.xfce.org/xfce/4.8pre3/src http://www.tx-us.xfce.org/archive/xfce/4.8pre3/src http://www.p0llux.be/xfce/xfce/4.8pre3/src http://www.ca-us.xfce.org/archive/xfce/4.8pre3/src
A tarball including all individual releases can be downloaded here:
http://archive.xfce.org/xfce/4.8pre3/fat_tarballs http://www.tx-us.xfce.org/archive/xfce/4.8pre3/fat_tarballs http://www.p0llux.be/xfce/xfce/4.8pre3/fat_tarballs http://www.ca-us.xfce.org/archive/xfce/4.8pre3/fat_tarballs
Today we are pleased to announce the third and hopefully final preview release of Xfce 4.8 which is set to be pushed out to the public on January 16th, 2011. Compared to Xfce 4.8pre2 this release mostly features translation updates and bug fixes.
With christmas and new year’s eve between 4.8pre2 and 4.8pre3 it comes as no surprise that for most components only a few issues were tackled.
Among other things we updated the default keyboard shortcuts to include monitor keys. The status icon of the file manager’s progress dialog is now properly hidden when the dialog is destroyed. It’s wallpaper plugin is now capable of handling filenames with spaces. The environment variables of commands launched from the Xfce run dialog were not set properly, so we fixed that so that commands launched from the dialog always inherit the environment of the Xfce session.
We also made the --reboot and --halt parameters of xfce4-session-logout
work again which previously simply logged out the active user. In order
to avoid a race condition at session startup and in order to speed
things up a little more we no longer use xrdb to update xft and cursor
settings and instead, update the related XSETTINGS properties ourselves.
In the window manager xfwm4, we aligned the time period required for a double click with that of normal applications. Via the hidden option “/general/mousewheel_rollup” one can now disable windows being rolled up via the mouse wheel. The window manager now also properly handles resolution changes in fullscreen windows like those appearing in games. Xfwm4’s application switcher now only appears once in cloned mode.
This may sound like a few useful fixes but it’s nothing compared to the amount of work that went into the new Xfce panel once again. Around 20+ known bugs and regressions were fixed. Here is a short excerpt of the complete changelog: Translation domains were fixed for external plugins, plugins can be reordered with DND again, double-clicking items in the item editor shows their preferences, dragging items to the item editor dialog removes them from the panel again, tasklist windows can now be filtered by monitor. Another issue that appeared recently and has now been fixed is the icon sizing in the notification area, also known as the systray.
Xfce 4.8pre3 also features a lot of translation updates, as can be seen in the complete changelog on
http://xfce.org/documentation/changelogs/4.8pre3
Since we’re following the Xfce release model for 4.8, we’d normally announce code freeze and the creation of early lifecycle support branches today. We decided against this because there are not enough people active to take care of all this at the moment. So we will continue fixing bugs in master branches as we did between 4.8pre2 and 4.8pre3.
We’re hoping that you will enjoy today’s release. Thanks a lot to everyone contributing this time around! We’re pretty sure 4.8 is gonna rock.
Kind regards,
The Xfce development team
P.S.: Happy new year everyone!
Xfce 4.8pre2 released!
Xfce 4.8pre2 is now available for download.
It includes the following releases of Xfce core components:
exo 0.5.5 gtk-xfce-engine 2.6.0 libxfce4ui 4.7.5 libxfce4util 4.7.4 libxfcegui4 4.7.0 thunar 1.1.5 thunar-vfs 1.1.1 xfce-utils 4.7.3 xfce4-appfinder 4.7.1 xfce4-dev-tools 4.7.3 xfce4-panel 4.7.6 xfce4-session 4.7.2 xfce4-settings 4.7.6 xfconf 4.7.4 xfdesktop 4.7.4 xfwm4 4.7.3
Release tarballs can be retrieved from the following mirrors (please note that it may take a few hours for the mirrors to catch up):
http://archive.xfce.org/xfce/4.8pre2/src http://www.tx-us.xfce.org/archive/xfce/4.8pre2/src http://www.p0llux.be/xfce/xfce/4.8pre2/src http://www.ca-us.xfce.org/archive/xfce/4.8pre2/src
A tarball including all individual releases can be downloaded here:
http://archive.xfce.org/xfce/4.8pre2/fat_tarballs http://www.tx-us.xfce.org/archive/xfce/4.8pre2/fat_tarballs http://www.p0llux.be/xfce/xfce/4.8pre2/fat_tarballs http://www.ca-us.xfce.org/archive/xfce/4.8pre2/fat_tarballs
Release notes for 4.8pre2
We are pleased to announce the second preview release of Xfce 4.8. This release marks the beginning of the string freeze. From today on until the final release, strings may no longer be changed in the master branch of Xfce core components. This will help translators to prepare their translations for the final release scheduled on January 16th, 2011.
For this release we focused on fixing bugs in all Xfce components. We managed to close a great number of them thanks to all the persons who reported them and tested proposed fixes quickly.
A few minor panel features were added despite feature freeze. We also managed to work on two long time requests: proper support for editing the application menu with menu editors (Alacarte being the one that we tested) and integration with the Compiz viewport. Of course, this release also features a lot of new and improved translations thanks to the amazing work of our translation teams.
A list of all changes is available on:
http://mocha.xfce.org/documentation/changelogs/4.8pre2
We hope you will enjoy this release. Please give us feedback by sharing your thoughts, blogging, tweeting, denting or by filing bug reports. With your help, 4.8 will be the best release ever (at least until 4.10)!
Kind regards and thanks to everyone who has contributed to this release,
The Xfce development team
Xfce 4.8pre1 released!
Xfce 4.8pre1 is now available for download.
It includes the following releases of Xfce core components:
exo 0.5.4 gtk-xfce-engine 2.6.0 libxfce4ui 4.7.4 libxfce4util 4.7.3 libxfcegui4 4.7.0 thunar 1.1.4 thunar-vfs 1.1.1 xfce-utils 4.7.1 xfce4-appfinder 4.7.1 xfce4-dev-tools 4.7.3 xfce4-panel 4.7.4 xfce4-session 4.7.1 xfce4-settings 4.7.4 xfconf 4.7.3 xfdesktop 4.7.2 xfwm4 4.7.1
Release tarballs can be retrieved from the following mirrors (please note that it may take a few hours for the mirrors to catch up):
http://archive.xfce.org/xfce/4.8pre1/src http://www.tx-us.xfce.org/archive/xfce/4.8pre1/src http://www.p0llux.be/xfce/xfce/4.8pre1/src http://www.ca-us.xfce.org/archive/xfce/4.8pre1/src
A tarball including all individual releases can be downloaded here:
http://archive.xfce.org/xfce/4.8pre1/fat_tarballs http://www.tx-us.xfce.org/archive/xfce/4.8pre1/fat_tarballs http://www.p0llux.be/xfce/xfce/4.8pre1/fat_tarballs http://www.ca-us.xfce.org/archive/xfce/4.8pre1/fat_tarballs
Release notes for 4.8pre1
The Xfce development team is proud to announce the first preview release for Xfce 4.8. Together with this preview release, the Xfce project announces the feature freeze for the final 4.8 release which is set to be pushed out to the world on January 16th, 2011.
This release incorporates major changes to the core of the Xfce desktop environment and hopefully succeeds in fulfilling a number of long time requests. Among the most notable updates is that we have ported the entire Xfce core (Thunar, xfdesktop and thunar-volman in particular) from ThunarVFS to GIO, bringing remote filesystems to the Xfce desktop. The panel has been rewritten from scratch and provides better launcher management and improved multi-head support. The list of new panel features is too long to mention in its entirety here. Thanks to the new menu library garcon (formerly known as libxfce4menu, but rewritten once again) we now support menu editing via a third-party menu editor such as Alacarte (we do not ship our own yet). Our core libraries have been streamlined a bit, a good examplle being the newly introduced libxfce4ui library which is meant to replace libxfcegui4.
Perhaps the most important achievement we will accomplish with Xfce 4.8 is that, despite suffering from the small size of the development team from time to time, the core of the desktop environment has been aligned with today’s desktop technologies such as GIO, ConsoleKit, PolicyKit, udev and many more. A lot of old cruft like has been stripped from the core as well, as has happened with HAL and ThunarVFS (which is still around for compatibility reasons).
Thanks to the awesome Transifex translation platform, our language teams have been able to update their translations at an incredible pace. Please include them when praising this release!
A complete list of all changes since the latest stable release is available on
http://mocha.xfce.org/documentation/changelogs/4.8pre1
Below you will find download information for Xfce4.8pre1. Please give our mirrors a few hours to synchronize. We hope you will enjoy this release, feel encouraged to blog and tweet about it! Feedback is welcome in all forms. Bugs can be reported in our bug tracker as usual. We need your help to make Xfce 4.8 our best release ever!
Kind regards and thanks to everyone who has contributed to this release,
The Xfce development team
Final exams, diplom thesis and thunar-volman
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!
Xfce 4.8 Schedule Changes
As the Xfce release manager, I’d prefer to be the bringer of good news. Unfortunately, we have to make some adjustments with regards to the Xfce 4.8 release schedule.
You may well remember last year’s chaos with the 4.6 release date. We’re trying our best not to repeat that and if it should happen again, we’ll at least keep you posted about the issues as good as we can.
So, what’s the deal with 4.8?
One thing that hasn’t changed much is that our development team is very small. A hobby project of this size requires a certain amount of time to be invested by each individual developer. Time not everyone has as much has he would like to dedicate to Xfce.
Today, Brian announced his absence for the coming months due to his new job, leaving 2-3 of our core components (xfdesktop, xfconf and xfce4-session) more or less unmaintained (aside from bugfixes). The good news is that Jérôme (who has recently started to improve xfce4-settings and port xfce4-session to libxfce4ui) and Daniel (the maintainer of the thunar-shares-plugin) have offered their help with xfdesktop and xfce4-session.
Brian is not the only one having little time at hand though. I’m preparing myself for my final university exams, so ideally I’d be sticking my nose into lecture notes all day long. I still have the time to write mails like this but there hasn’t been much activity around thunar and related projects lately.
Again, I’m really happy to see people volunteering to help because that’s what we need right now. There’s a lot left to do before we can release 4.8. Let me get to that now.
As some of might have heard, thunar was ported to GIO this summer. Through GVfs, GIO brings new features such as SMB, SFTP, FTP browsing which some people use one a daily basis already. Now, GVfs has turned out to be problematic for us for various reasons. At first it shipped a HAL-based volume monitor with a hard-coded dependency on gnome-mount. Today it ships a volume monitor based on gnome-disk-utility (uses DeviceKit-disks itself) which proves to be inconsistent and somewhat incompatible to the HAL mounting code in exo.
The result: thunar-volman (not part of the core but important for thunar nonetheless) and xfdesktop will have to be ported to udev (the mounting being done with GIO, ideally). I’ve started working on this but this is far from being finished.
Question to the other developers: Didn’t xfce4-session use HAL for logging out and stuff? We might have to look into replacing those portions of code with something based on ConsoleKit, I guess?
HAL/udev is not the only issue however. With Xfce 4.8 we’ll be replacing libxfcegui4 with a new library called libxfce4ui. Not all core applications (again, xfdesktop being one of them, I think) have been ported to it yet. In most cases, this is no big deal and probably could be resolved within a few days though.
Then we have garcon, the much improved menu library that is supposed to replace libxfce4menu. At the time of writing the only feature it is lacking that is crucial for 4.8 is file system monitoring. We’ll probably implement basic monitoring like we had in libxfce4menu. Work on this hasn’t started yet.
Also, xfdesktop needs to be ported not only from ThunarVFS/HAL to GIO/udev but also from libxfce4menu to garcon.
So, as you can see there is quite a lot of work ahead of us. Taking into account the little free time some of us have these days, we’ve decided to postpone the 4.8 release until June 12th instead of April 12th. The entire release phase in our schedule has been moved by two months in time, as you can see on the official schedule wiki page:
http://wiki.xfce.org/releng/4.8/schedule
To be honest, I wouldn’t consider this new date fixed either. It all depends on how much we can do until the feature freeze on April 1st. I’m optimistic that meeting the deadlines is possible though.
For all of you who can’t wait until June, try out our development releases which are announced on http://identi.ca/xfce. I have at least something good to share: For a few weeks now I’ve been running Fedora 12 with a mixture of Xfce 4.6 packages and development package from the upcoming 4.8 series and the new components have proven to be very stable already.
I’m especially happy about the new panel which works almost flawlessly (except for a few dual head issues) and not only supports real transparency and more comfortable launcher creation based on garcon, but is also compatible to panel plugins written for Xfce 4.6. (Good work, Nick!)
So, I guess this is it. A mixture of good and bad. I hope nobody is too disappointed. As always, we’re doing the best we can.
Cheers!
Thunar-volman and the deprecation of HAL in Xfce
Last week I started looking at thunar-volman (a program that performs certain actions when new devices are plugged in) with the goal to make it compatible with the latest release of thunar which uses GIO instead of ThunarVFS for almost everything that takes place under the hood.
Until now, volume management (monitoring and mounting) in Xfce was done through HAL, the hardware abstraction layer that is currently being deprecated and dropped by major distributions. The functionality previously provided by HAL has been moved into udev, udisks (formerly known as DeviceKit-disks) and upower (formerly known as DeviceKit-power).
Volume management is transparently supported by GIO, meaning that applications don’t have to worry about the backend implementation. It should, in theory, not matter whether HAL is used or udev/udisks. Unsurprisingly, in reality, things are not that trivial, mainly for two reasons:
- Due to its focus on file management, GIO only supports monitoring and detecting storage devices (DVD drives, USB sticks etc.). There is no way to be notified when e.g. a digital camera or a portable media player is plugged in. This is critical for the functionality of thunar-volman which until now supported everything from cameras, media players, blank CDs/DVDs, audio CDs, PDAs and printers to input devices like keyboards, mice and tablets.
- Mounting volumes with udisks seems to be somewhat incompatible with HAL. I tried to mount volumes with thunar-volman and exo-mount (both implemented on top of HAL) and was for the root password upon unmounting in Thunar (using GIO and gnome-disk-utility/DeviceKit-disks). It seems like volumes mounted with HAL are assumed to be mounted by a different than the current user and thus, require root privileges to be unmounted.
HAL being deprecated and somewhat incompatible with udisks, what are the consequences for Xfce, and for thunar and thunar-volman in particular?
Let us, for a moment, assume Xfce 4.8 and thunar 1.0 were released as they are today, with thunar using GIO (and udisks instead of HAL in all major Linux distributions) and the rest (like thunar-volman and exo-mount) depending on HAL. As mentioned before, exo-mount and thunar wouldn’t work together in multi-user setups. Thunar would no longer detect cameras, PDAs, audio CDs, blank disks, mice, keyboards, tablets, media players and thunar-volman would end up being completely useless, as it is not detecting devices by itself. I think it is safe to say that this is not what we want.
In the following, I will focus on how to deal with thunar-volman. The rest of Xfce faces a similar roadmap, however. With regards to thunar-volman, there are (at least) three sane options:
- Drop thunar-volman and only support auto-mounting storage devices from now on, directly implemented in thunar. What is very obvious about this solution is that a lot of possibly useful functionality is lost.
- Port thunar-volman to (g)udev/udisks/GIO and make it a standalone daemon so that thunar no longer has to spawn it when new devices are plugged in. The advantage of this approach is that thunar only needs to depend on GIO and doesn’t have to implement the device detection part.
- Port thunar-volman to (g)udev/udisks/GIO as described above and make thunar depend on (g)udev for device detection. Spawn thunar-volman when devices are added/removed. The advantage over the previous approach is that thunar-volman doesn’t have to run permanently as a daemon. The additional thunar dependency on (g)udev could be seen as a disadvantage but on the other hand, it basically replaces another (HAL).
Now, everyone knows that programmers are lazy people. So, in the hope of being able to save some work, I started a survey on the usage of thunar-volman. The idea was to find out which of its features are used most and whether there are some that nobody really cares about. Here are the results:
=======================================================================================
Feature #Users Percentage
---------------------------------------------------------------------------------------
Mount removable drives when hot-plugged 86 92.5%
Mount removable media when inserted 83 89.2%
Browse removable media when inserted 69 74.2%
Cameras: Import digital photographs when connected 31 33.3%
Play video CDs and DVDs when inserted 31 33.3%
Play audio CDs when inserted 30 32.3%
Burn a CD or DVD when a blank disc is inserted 21 22.6%
Portable Media Players: Play music files when connected 11 11.8%
Auto-run programs on new drives and media 7 7.5%
Automatically run a program when a printer is connected 7 7.5%
Auto-open files on new drives and media 6 6.5%
Sync Palm devices when connected 5 5.4%
Automatically run a program when an USB keyboard is connected 3 3.2%
Automatically run a program when an USB mouse is connected 3 3.2%
Automatically run a program when a tabled is connected 2 2.2%
Sync Pocket PC devices when connected 2 2.2%
=======================================================================================
Thunar Volume Manager Usage Survey with 93 participants
According to the results of this survey, auto-mounting and browsing of removable drives and media have highest priority among the 93 participating thunar-volman users. This more or less covers the functionality we could cover with GIO alone (plus automatically running a program when new drives and media are inserted). However, a third of the users also use thunar-volman for importing photographs from digital cameras and for playing video and audio CDs as well as DVDs automatically. Almost a 25 percent of all users use thunar-volman to start their favorite burning software when a blank CD or DVD is inserted. Slightly more than 10 percent want thunar-volman to start playing music on portable media players when they are plugged in. Printers and Palms are also somewhat relevant.
This survey confirms my expectations that handling storage devices alone is not enough even though they clearly are the most important use case for thunar-volman. Our users seem to like the flexibility of thunar-volman and make use of it. This disqualifies option 1 and leaves us with options 2 and 3. I’m inclined to avoid another daemon and go for number 3.
In preparation for porting thunar and thunar-volman to udev/udisks/GIO, I’ve created a wiki page to collect information about how we can reliably distinguish the different device types based on udev properties: http://wiki.xfce.org/dev/thunar-volman-udev. If you have blue-ray disks, video CDs, a digital camera, a Pocket PC, a Palm, a USB printer or a graphics tablet, you could make me very happy if you inserted them or plugged them in and sent me the output of udevadm info --export-db to my Xfce email address together with a short hint what devices you’ve plugged in. Alternatively, you can paste/upload the output somewhere on the internet and comment on this blog post, and thereby help making future versions of Xfce better.
Cheers!
Donations, FOSDEM
It’s been a while that I used PayPal for anything, so it came as a nice surprise that when I logged in yesterday I was presented with 60€ worth of donations for Thunar and Xfce as a whole. Thanks to Michael Gstettenbauer, James Wallen and Alin Anton (I hope the names are correct), you guys rock!
Edit: Of course this money will be used for Xfce activities and stuff exclusively, not for my own private expenses. ;)
Another interesting piece of information I noticed last night is that despite our inactivity with regards to FOSDEM, there is a developer room reserved for cross desktop talks at next year’s event. I haven’t talked to anyone yet but since they excplicitely mention Xfce as possible participants, I guess there still is a chance for one or two presentations related to Xfce. Anything you’d like us to talk about?
News From Busyland
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…
New Personal Bugzilla Policy
I’m herewith announcing a new policy I’m going to follow when dealing with reports on bugzilla.xfce.org. This one goes out to all ignorant wise-asses among you claiming to be superior to us, thinking they are the center of the universe:
If you behave disrespectful, insulting, arrogant or demanding when reporting bugs or feature requests, I will close your bugs with WONTFIX. I don’t care about your name, I don’t care about your title, and I don’t care about your reputation. I do care about social skills and willingness to do your homework. Contributions of all sorts are welcome but as soon as you’re impolitely trying to tell me what I have done wrong or what I have to do in your opinion, you’re out. I call it the social intelligence requirement and it is a must. The more experience you claim to have the higher I’ll set the barrier for you to fulfill the requirement.
Thanks for your attention.
Using Tumbler in Client Applications
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:
- An array of URIs for which thumbnails should be generated
- An array of MIME types for these URIs (each element corresponding to the URI with the same index in the URI array)
- The thumbnail flavor to generate for the URIs (
normalis 128x128px,largeis 256x256px, ...) - The scheduling mechanism to be used for the request (foreground, background, ...)
- 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)
!["file:///tmp/foo.png"](http://gezeiten.org/post/2009/10/"file%3A///tmp/foo.png"){kind=link}
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:
Startedis emitted together with the request handle as soon as the service starts processing the URIs of the request.Readyis 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.Erroris 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.Finishedis 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,GetFlavorsandGetSchedulers. ASupportedChangedsignal 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
GtkTreeViewor 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.