Jannis Pohlmann Personal website


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

Entries feed - Comments feed

Sunday, November 7 2010

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):


A tarball including all individual releases can be downloaded here:


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


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

Tuesday, January 26 2010

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:


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.


Thursday, March 26 2009

libxfce4menu to be renamed to gdesktopmenu

Now that all Xfce dependencies have been removed from libxfce4menu, I'm planning to rename it to something more generic. Travis Watkins from Alacarte has expressed interest in helping with writing the XfceMenuEditor (err GDesktopMenuEditor) part. He is also working on Vala bindings for the library.

With a more complete API and polished code perhaps we can even move gdesktopmenu over to freedesktop.org ... who knows.

Sunday, February 22 2009

Thoughts on libxfce4menu for Xfce 4.8

I've been hacking on libxfce4menu in a local branch for the last couple of days and I think I'm finally happy with the API changes I have done. The version that will be shipped with Xfce 4.6 has a clean API for reading from menus but unfortunately it lacks support for menu merging and is not really usable for writing a menu editor.
 So there is a lot to improve for Xfce 4.8.

libxfce4menu uses a GObject class called XfceMenu as a representation of the entire menu tree. The downside of this approach is that some tree operations are hard to implement if possible at all. In a DOM structure child elements are ordered. In XfceMenu, they are not. In fact, the concept of a child element in XfceMenu is problematic. In a DOM all child elements are treated equal. XfceMenu on the opposite treats Menu elements different than e.g. AppDir elements. It throws them into different lists. And that's why merging is hard to implement with the current API. There is no DOM representation of the tree and thus, XfceMenu does not know whether an AppDir element came before a certain DirectoryDir element for instance. But when doing merges this matters. Actually, in most cases this won't be a problem, but theoretically it is. If you don't care about the order, you break the specification.

So, libxfce4menu in Xfce 4.8 is going to build a DOM representation for the menu tree to make merging and other things easier to implement.

But there still is the goal to improve the API with regards to menu editing support. To work properly, menu editors need to know information about the menu tree after parsing the root .menu file - before any modifications. This is something the current implementation of libxfce4menu hides completely.

So, here is what I came up with for 4.8. First of all, you have several classes:

  1. GNode is used for the DOM representation.
  2. Every node has a data object which is an instance of XfceMenuNode, except for <Menu> nodes.
  3. To parse a menu there is XfceMenuParser which creates a GNode DOM representation for a .menu file. It doesn't do merging, so you'll only get the DOM for the XML of the .menu file itself, not of other .menu files specified using <MergeFile> elements.
  4. To load and merge the rest, there is XfceMenuMerger. It takes the DOM representation generated by the parser and basically does everything that explained in this part of the specification.
  5. XfceMenu, XfceMenuLayout and XfceMenuItem will still be around. They take the merged DOM representation from XfceMenuMerger, load all the desktop entries and wrap the entire information about the resulting menu tree with a nice and easy-to-use API. There will also still be a class for monitoring and stuff like that.
  6. And then there is a nother class: XfceMenuEditor which takes the DOM representation from XfceMenuParser and provides functions for operations required by graphical menu editors. It will be able to add <Move> elements if the user moves menus around, it can add <Deleted> elements if the user decides to hide a menu and so forth. It will also support writing the tree to a .menu file, maybe using another class called XfceMenuWriter.
  7. There will be an interface called XfceMenuTreeProvider which is implemented by XfceMenuParser, XfceMenuMerger and XfceMenuEditor.

The only thing that is not covered is how desktop entries are edited. But they are not really part of the menu tree anyway. Here are two uses cases for the usage of the API presented above.

Reading Menus (For Hardliners)

Someone wants to read and build the menu from a file called applications.menu.
XfceMenuParser *parser;
XfceMenuMerger *merger;
XfceMenu *menu;
GError *error = NULL;
GFile *file;

file = g_file_new_for_path ("applications.menu");
parser = xfce_menu_parser_new (file, &error);
g_object_unref (file);

/* The optional second argument is a GCancellable */
if (!xfce_menu_parser_run (parser, NULL, &error))
g_error (error->message);

g_error_free (error);
g_object_unref (parser);

merger = xfce_menu_merger_new (XFCE_MENU_TREE_PROVIDER (parser));
g_object_unref (parser);

if (!xfce_menu_merger_run (merger, NULL, &error))
g_error (error->message);

g_error_free (error);
g_object_unref (merger);

menu = xfce_menu_new_from_tree_provider (XFCE_MENU_TREE_PROVIDER (merger));
g_object_unref (merger);

/* Now do something with the menu */

g_object_unref (menu);

Reading Menus (The Easy Way)

Of course there will be a much easier-to-use function for creating an XfceMenu, like this one:

XfceMenu *xfce_menu_create_for_file (GFile   *file, 
GError **error);

Writing a Menu Editor

XfceMenuParser *parser;
XfceMenuEditor *editor;
XfceMenuWriter *writer;

/* I'll leave out the error handling this time */
parser = xfce_menu_parser_new (file);
xfce_menu_parser_run (parser, NULL, &error);

editor = xfce_menu_editor_new (XFCE_MENU_TREE_PROVIDER (parser));
g_object_unref (parser);

/* Use XfceMenuMerger and XfceMenu here to get an XfceMenu object for use in the GUI */

/* Assuming that the user moves the menu "A/B" to "C/D" using the GUI */
xfce_menu_editor_move (editor, "A/B", "C/D");

/* Assuming that the user decided to hide the menu "Accessories" */
xfce_menu_editor_set_deleted (editor, "Accessories", TRUE);

/* Save the menu to a file, assuming we have a GFile object to write to */
writer = xfce_menu_writer_new (XFCE_MENU_TREE_PROVIDER (editor));
xfce_menu_writer_write (writer, file, NULL, &error);
g_object_unref (writer);

Of course nothing of this is final. This is just what I came up with today. But I can imagine that this would work quit well.

So, what do you think?

Tuesday, November 25 2008

December plans and recent Xfce developments

I’m currently planning the last few things for my trip to the UDS Jaunty, taking place in Mountain View, California from December 8th to 12th. It looks like Brian will pick me up at San Francisco International on the day of my arrival. We’ll probably have something to eat before he drops me off at the hotel. What could possibly be more awesome than that? I’m very excited to say at least. I’ve also received my hotel reservation already and it looks like I’ll have a twin room on my own for half of my stay.

Ok, back to some Xfce related topics. Last week I submitted our FOSDEM devroom request. We’ll be notified before 2008-11-30 whether we the request is accepted or not. Five days left until we’ll know more - keep your fingers crossed if you haven’t already!

Nick and I have recently started to fix bugs in Thunar. So far we’ve managed to fix and close about a dozen bugs I think. We’re forced to do this due to Benny’s absence but I have to say it’s actually quite a lot of fun to fix bugs in other people’s code! In the end we’ll both have better understanding of how Thunar works. This will soon give us the possibility to push things forward. Not only am I planning to replace thunar-vfs with GIO/GVfs after 1.0 is released along with Xfce 4.6; there are more things that need to be done: adding support for xfconf might be worth considering as Thunar is now one of the last components that still stores its configuration using XfceRc. Also, we could think about using libxfce4menu for detecting installed applications which was actually one of the most important use cases of it that we had in mind before I started writing that library. And of course the list of possible features and cleanups doesn’t end here …

I also have some bad news. It looks like we’re having a bit of a problem with our 4.6 release schedule again. Due to the delay of the second beta, we were forced to delay the third beta as well. Maybe we can sort of fix that by leaving out the third release candidate but we still have to discuss how to handle this.