Jannis Pohlmann Personal website

Jannis

I am an open source enthusiast, student and musician from Lübeck, Germany. In my free time I enjoy hacking on Xfce and Lunar Linux. I've been a member of both teams since about 2005. Besides developing software, I love to listen to and play music (Guitar, Bass and Drums) and hang out with friends.

Contact me via jannis@xfce.org. My public PGP key is 0x354AFBA6. You can download it from here.

My CV is also available for download.

Tag - community

Entries feed - Comments feed

Sunday, January 17 2010

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:

  1. 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.
  2. 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:

  1. 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.
  2. 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.
  3. 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!

Tuesday, December 1 2009

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?

Sunday, November 1 2009

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.

Monday, September 14 2009

Design of the Thunar Progress Dialog

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!

Sunday, September 13 2009

Xfce 4.8 Release Cycle Information

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!

- page 3 of 5 -