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 - thunar

Entries feed - Comments feed

Friday, April 24 2009

Thunar/GIO - Quick Status Report

I've started hacking on the migration of Thunar to GIO on April 9th. In about 61 commits, I've reduced the original number of ThunarVFS references in the Thunar source code dramatically. The most important and probably most time-consuming part of this work is only mentioned briefly on those pages: rewriting all recursive copy/move/trash/restore/chmod/chgrp/chown jobs -- by now most of the jobs have been rewritten based on GIO and the new ThunarJob framework ... and Thunar still works (for me at least)!

All in all, I suppose that about a third of the implementation work is done. Ok, maybe just a quarter, but an important one. I now have a very good overview over the source code and I'm almost done with one of the most critical parts of the migration.

If you want to know how that looks like for me, here's a screenshot:

Lunar Linux 20090423

These are the most important/big things that are still waiting for me:

  • Replace ThunarVFSVolumeManager with GFileMonitor. Volume management is a large and complex subsystem of both ThunarVFS and GIO.
  • Load ThunarFile objects asynchronously. This will be a pain. A lot of functions will have to be split up to fit into the asynchronous concept.
  • Move the thumbnail related code into exo

These two are a bit out of scope but very important nonetheless:

  • Integrate functionality similar to Gigolo (remote/virtual places management) into the file manager.
  • Write GNOME-independent GIO extensions for volume management and the trash.

On a side node: Xubuntu 9.04 is available as of today! Go and grab it if you're interested in a nice distro based on Xfce. If you're interested in the Xubuntu development, you'll be able to meet Stephan, several Xubuntu folks and me at the Ubuntu Developer Summit in Barcelona from May 25th-29th. I'm very excited already!

Tuesday, April 7 2009

Writing Your Own GIO Jobs

After having moved into a new apartment I'm now back at working on my thesis about Thunar. There are a few things which are solved very differently in GIO than in ThunarVFS. One of them is the way jobs are handled. A job basically is a task which may take a while to run and thus is executed in a separate thread (so it doesn't block the GUI).

ThunarVFS has a framework called ThunarVfsJob. It lets you create different kinds of jobs e.g. for changing file permissions recursively or for computing the total number of files and the total size of a directory. These jobs report back to the GUI thread using signals such as "new-files" (when new files are added and need to picked up by the GUI) or "progress".

GIO has something similar ... but it's not so obvious how it works. When I tried to figure out how to migrate ThunarVfsJob to GIO I thought: hey, GIO must have something like this already! It contains several job-like functions such as g_file_copy_async() after all.

So here's what I found out after spending some time on reading gfile.c and glocalfile.c: there is a job framework in GIO ... but it's hidden behind easy-to-use asynchronous functions. It's based on GCancellable, GAsyncResult and a bunch of callback types. It uses GIOScheduler internally to glue everything together to something that is actually pretty convenient (but still kinda tricky).

So, what do you need in orderto write your own jobs in the GIO style?

First of all, you need an example task. I picked counting files and computing the total size of a directory to understand how it works. What we want is an asynchronous function which does exactly that and uses a callback to report the progress back to the GUI thread ... just like g_file_copy_async() does.

First of all, you define the callback type and two functions for starting the job (sync and async version):

The Public API

typedef void (*GFileCountProgressCallback) (goffset  current_num_files,
                                            goffset  current_num_bytes,
                                            gpointer user_data);

static gboolean 
g_file_deep_count (GFile                     *file,
                   GCancellable              *cancellable,
                   GFileCountProgressCallback progress_callback,
                   gpointer                   progress_callback_data,
                   GError                   **error);

 static void
 g_file_deep_count_async (GFile                     *file,
                          int                        io_priority,
                          GCancellable              *cancellable,
                          GFileCountProgressCallback progress_callback,
                          gpointer                   progress_callback_data,
                          GAsyncReadyCallback        callback,
                          gpointer                   callback_data);

The Implementation

All the function g_file_deep_count_async() will do is to create a GSimpleAsyncResult, put the callback information into it and then tell the GIOScheduler to run the job. Here's how that looks like:

static void 
g_file_deep_count_async (GFile                     *file,
                         int                        io_priority,
                         GCancellable              *cancellable,
                         GFileCountProgressCallback progress_callback,
                         gpointer                   progress_callback_data,
                         GAsyncReadyCallback        callback,
                         gpointer                   callback_data)
{
  GSimpleAsyncResult *result;
  DeepCountAsyncData *data;

  g_return_if_fail (G_IS_FILE (file));

  data = g_new0 (DeepCountAsyncData, 1);
  data->file = g_object_ref (file);
  data->progress_cb = progress_callback;
  data->progress_cb_data = progress_callback_data;

  result = g_simple_async_result_new (G_OBJECT (file), 
                                      callback,
                                      callback_data, 
                                      g_file_deep_count_async);
  g_simple_async_result_set_op_res_gpointer (result, 
                                             data, 
                                             (GDestroyNotify) deep_count_async_data_free); 

  g_io_scheduler_push_job (deep_count_async_thread,
                           result, 
                           g_object_unref, 
                           io_priority, 
                           cancellable);
}

DeepCountAsyncData is a simple struct which needs no further explanation, I think. First data with callback and user data information is added to the GSimpleAsyncResult and then the job is added to the GIOScheduler. As you can see, there is another function involved: deep_count_async_thread. This is the function which runs in a separate thread and does most of the work (well, not quite ... but almost). Here's how it looks like:

static gboolean
deep_count_async_thread (GIOSchedulerJob *job,
                         GCancellable    *cancellable,
                         gpointer         user_data)
{
  GSimpleAsyncResult *res;
  DeepCountAsyncData *data;
  gboolean            result;
  GError             *error = NULL;

  res = user_data;
  data = g_simple_async_result_get_op_res_gpointer (res);

  data->job = job;
  result = g_file_deep_count (data->file, 
                              cancellable, 
                              data->progress_cb != NULL ? deep_count_async_progress_callback : NULL, 
                              data, 
                              &error);

  if (data->progress_cb != NULL)
    g_io_scheduler_job_send_to_mainloop (job, (GSourceFunc) gtk_false, NULL, NULL);

  if (!result && error != NULL)
    {
      g_simple_async_result_set_from_error (res, error);
      g_error_free (error);
    }

  g_simple_async_result_complete_in_idle (res);

  return FALSE;
}

As you can see it runs the synchronous function g_file_deep_count() and makes sure the progress callback is called at least once. It does one more thing though: it defines it's own progress callback: deep_count_async_progress_callback. This is required for the real progress callback to be called inside the GUI thread. This is the code for the internal callback:

static gboolean
deep_count_async_progress_in_main (gpointer user_data)
{
  ProgressData       *progress = user_data;
  DeepCountAsyncData *data = progress->data;

  data->progress_cb (progress->current_num_files, 
                     progress->current_num_bytes, 
                     data->progress_cb_data);

  return FALSE;
}

static void
deep_count_async_progress_callback (goffset  current_num_files,
                                    goffset  current_num_bytes,
                                    gpointer user_data)
{
  DeepCountAsyncData *data = user_data;
  ProgressData       *progress;

  progress = g_new (ProgressData, 1);
  progress->data = data;
  progress->current_num_files = current_num_files;
  progress->current_num_bytes = current_num_bytes;

  g_io_scheduler_job_send_to_mainloop_async (data->job, 
                                             deep_count_async_progress_in_main, 
                                             progress, 
                                             g_free);
}

deep_count_async_progress_callback() is called from within the job thread. It then tells the scheduler to call deep_count_async_progress_in_main from the GUI thread. And finally deep_count_async_progress_in_main calls the real progress callback e.g. to update the GUI.

Now you still haven't seen any code related to counting files and computing the total file size of a directory ... let's get to that now. Here's the synchronous deep count function which is called from within the job thread:

static gboolean  
g_file_deep_count (GFile                     *file,
                   GCancellable              *cancellable,
                   GFileCountProgressCallback progress_callback,
                   gpointer                   progress_callback_data,
                   GError                   **error)
{
  ProgressData data = {
    .data = NULL,
    .current_num_files = 0,
    .current_num_bytes = 0,
  };

  g_return_val_if_fail (G_IS_FILE (file), FALSE); 

  if (g_cancellable_set_error_if_cancelled (cancellable, error))
    return FALSE;

  return g_file_real_deep_count (file, 
                                 cancellable, 
                                 progress_callback, 
                                 progress_callback_data, 
                                 &data, 
                                 error);
}

Damn ... it still doesn't do any real work! Ok, but this time there's no big rat-tail of nested function calls anymore, I promise. There's just one function left: g_file_real_deep_count(). Before we can call it, however, g_file_deep_count() has to initialize the progress data. After that we can call g_file_real_deep_count() recursively and do something useful. Here we go:

static gboolean
g_file_real_deep_count (GFile                     *file,
                        GCancellable              *cancellable,
                        GFileCountProgressCallback progress_callback,
                        gpointer                   progress_callback_data,
                        ProgressData              *progress_data,
                        GError                   **error)
{
  GFileEnumerator *enumerator;
  GFileInfo       *info;
  GFileInfo       *child_info;
  GFile           *child;
  gboolean         success = TRUE;
  
  g_return_val_if_fail (G_IS_FILE (file), FALSE);
  if (g_cancellable_set_error_if_cancelled (cancellable, error))
    return FALSE;

  info = g_file_query_info (file, 
                            "standard::*", 
                            G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS, 
                            cancellable, 
                            error);

  if (g_cancellable_is_cancelled (cancellable))
    return FALSE;

  if (info == NULL)
    return FALSE;

  progress_data->current_num_files += 1;
  progress_data->current_num_bytes += g_file_info_get_size (info);

  if (progress_callback != NULL)
    {
      /* Here we call the internal callback */
      progress_callback (progress_data->current_num_files, 
                         progress_data->current_num_bytes, 
                         progress_callback_data);
    }

  if (g_file_info_get_file_type (info) == G_FILE_TYPE_DIRECTORY)
    {
      enumerator = g_file_enumerate_children (file, 
                                              "standard::*", 
                                              G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS, 
                                              cancellable, 
                                              error);
    
      if (!g_cancellable_is_cancelled (cancellable))
        {
          if (enumerator != NULL)
            {
              while (!g_cancellable_is_cancelled (cancellable) && success)
                {
                  child_info = g_file_enumerator_next_file (enumerator, 
                                                            cancellable, 
                                                            error);

                  if (g_cancellable_is_cancelled (cancellable))
                    break;

                  if (child_info == NULL)
                    {
                      if (*error != NULL)
                        success = FALSE;
                      break;
                    }

                  child = g_file_resolve_relative_path (file, g_file_info_get_name (child_info));
                  success = success && g_file_real_deep_count (child, 
                                                               cancellable, 
                                                               progress_callback, 
                                                               progress_callback_data, 
                                                               progress_data, 
                                                               error);
                  g_object_unref (child);
                  g_object_unref (child_info);
                }

              g_object_unref (enumerator);
            }
        }
    }

  g_object_unref (info);

  return !g_cancellable_is_cancelled (cancellable) && success;
}

And that's it. We can now compute the number of files and the total size of a directory recursively using a GCancellable and one or two callbacks. All of this is done using threads, so you don't have to worry about blocking your GUI main loop.

If you want to see this in action, visit the job framework page in my thesis wiki and download deepcount.c and the Makefile.

Friday, March 20 2009

Thesis: Migrating Thunar to GIO

I've semi-officially (whatever that means) started working on my thesis on migrating Thunar from ThunarVFS to GIO. I'll work on it in public. That means research material, testing results, status reports and of course the code will be publically available in a read-only wiki and our Subversion repository in a special branch respectively.

I'm always open to suggestions and opinions. Just drop me a mail if you have something to say.

If everything goes as planned (err, did I really sayplanned?) GIO will land in Thunar 1.2 which is supposed to be released along with Xfce 4.8. There's no warranty for this though.

Saturday, March 14 2009

A Day Like Any Other

After having finished watching Barfly, I kinda felt like I had to sum up the day. It went like this:

That's it.

There won't be many days like this in the next few weeks. I'm about to move in with a friend of mine at the beginning of next month. I'm going to start working on my thesis about Thunar next week. I still have a voluntary oral exam in software verification ahead of me in 12 days (I think ...) and of course I need to find someone to take over the appartment I'm currently living in. Lots and lots of things to keep me more than busy.

Wednesday, December 24 2008

Topics raised at UDS

Ok, this post is long overdue and has been around as a draft for more than a week now, so here it is. As readers of this weblog already know, I was at the Ubuntu Developer Summit from December 8th to 12th. We had quite a few discussions on topics I'm interested in outside the scope of the official sessions held at UDS. Let me just list them here in random order:

Buildbot

Arnaud Quette told me about Buildbot which can be used to test your repository for compilation errors on various systems. I suppose it can be a real time saver if you want your project to compile on a variety of distributions and UNIX flavors and want immediate response as to whether compilation is going to succeed on these. That way you don't have to wait for packagers and users to report compilation errors back to you and don't have to enter that typical ping pong developer-reporter dialog. Buildbot not only catches compilation errors but is also capable of sending notification emails and provides detailed information about the compile log and so on. It's implemented based on a server/client concept where each client tests compilation on one system and the server collects data from the clients. By using virtualization you can set up server and clients on the same machine. This would be very nice to have for Xfce but I suppose it would require another dedicated server just for running all these compilations. If anyone is interested in looking in to that, I'd be happy to establish contact to someone from Buildbot to provide you with more information. As a funny coincidence, Frédéric Péters recently announced build.gnome.org which is a great example of Buildbot usage.

Thunar and GIO

I talked to Christian Kellner about GIO/GVfs a bit in order to get information on how remote/virtual filesystems work. One thing I've thought about is how to allow for a list of user-defined remote/virtual filesystems which show up in the side pane of Thunar. There are different approaches to that. One is to use bookmarks which seems to be what, according to Christian, Nautilus does right now. While this seems to work quite well it seems to confuse users a bit. Personally, I'd like to see them separated from bookmarks. There has been a proposal for Nautilus to make the side pane look better by using sections. One thing I could imagine would be to have a "Virtual Volumes" section listing the user-defined filesystems and provide some sort of GUI for creating/removing/editing these. From what I've heard there also is a third approach, which is to make remote filesystems to appear as fake volumes in HAL or DeviceKit. I'll have to look into that in order to decide what the best way to go is, I guess.

PulseAudio and GStreamer

PulseAudio and GStreamer: We discussed the limited PulseAudio backend for GStreamer in a group of up to five people and agreed that it really needs improvement (as in more tracks have to be added to the GstMixer interface) if we don't want users to be able to control PulseAudio through the mixer applications they know. PulseAudio-specific applications like pavucontrol are not really what we want them to use.

Xubuntu Remix for Netbooks

During one of the Xubuntu sessions I talked to a member of the Ubuntu Mobile team about Xfce in general, the modularity of Xfce and the dependencies it has. He seemed to be very interested in it but he was also worried about Xfce becoming less lightweight, eating up more memory and disk space. It wasn't the first time during UDS that someone mentioned LXDE and asked me about my opinion on it. Two main reasons for Xfce being lightweight always were the small number of dependencies and applications which you could call the Xfce stack. With more and more applications and libraries being added, Xfce naturally feel less lightweight, even if these applications are not considered a part of the core desktop. You always have to keep that in mind. It seems like the high modularity of Xfce compensates parts of that and is why people are interested in Xfce in the context of mobile devices. Despite being modular and somewhat lightweight, Xfce also has improved in terms of user experience lately. I think we can push this even further. Giving accessibility more attention might also be worth considering. Usability is something I don't really see in LXDE (yet). That's what I usually tell people if they ask me for my opinion on it.

- page 4 of 5 -