Category Archives: Xfce


i think i’ve sorted out some of my desktop font issues, and created a few more in the process.

for a long time, i’ve had to deal with occasionally jagged, hard-to-read fonts when viewing webpages, because i ran my xfce desktop without any font antialiasing.

i’ve always hated the way modern desktop environments try to “fool” my eyes with antialiasing and subpixel hinting to convince me that a group of square pixels can be smoothed into round shapes. turning off antialiasing tends to make the rounder fonts, especially serif fonts, look pretty bad at large sizes, as seen here:

display issues

my preferred font for the desktop and the web is verdana, which looks pretty good without antialiasing. but most websites use other fonts, so rather than force one size of verdana everywhere (which causes flow/layout issues), i turned on antialiasing for my entire desktop, including my preferred browser, and started disabling antialiasing where needed.

before and after font settings:

before/after settings

i tried the infinality patchset for freetype, but unfortunately none of the eselect configurations produced the crisply rounded antialiased text the patches are known for. i rebuilt freetype without the patchset, and went into /etc/fonts to do some XML hacking.

while eselect-fontconfig offers painless management of existing presets, the only way to customize one’s setup is to get into nitty-gritty text editing, and font configs are in XML format. this is what i ended up with:

$ cat ~/.fonts.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<match target="font">
    <edit name="antialias" mode="assign">
<match target="font" >
    <test name="size" qual="any" compare="more">
    <edit name="antialias" mode="assign">
<match target="font" >
    <test name="pixelsize" qual="any" compare="more">
    <edit name="antialias" mode="assign">
<match target="pattern">
    <test qual="any" name="family"><string>Helvetica</string></test>
    <edit name="antialias" mode="assign">

let’s step through the rules:

first, all antialiasing is disabled. then, any requested font size over 11, or anything that would display more than 16 pixels high, is antialiased. finally, since the common helvetica font really needs to be antialiased at all sizes, a rule turns that on. in theory, that is — firefox and xfce both seem to be ignoring this. unless antialiasing really is enabled at the smallest sizes with no visible effect, since there are only so many pixel spaces available at that scale to “fake” rounded corners.

a test webpage shows the antialiasing effect on different fonts and sizes:

desktop and browser fonts

besides the helvetica issue, there are a few xfce font display problems. xfce is known for mostly ignoring the “modern” xorg font config files, and each app in the desktop environment follows its own aliasing and hinting rules. gvim’s monospace font is occasionally antialiased, resulting in hard-to-read code. the terminal, which uses the exact same font and size, is not antialiased, since it has its own control for text display.

the rest of the gtk+ apps in the above screenshot are size 10 verdana, so they have no antialiasing, being under the “size 11″ rule. firefox doesn’t always obey the system’s font smoothing and hinting settings, even with the proper options in about:config set. unlike user stylesheets, there’s no way to enforce desktop settings with something like !important CSS code. i haven’t found any pattern in what firefox ignores or respects.

also, i haven’t found a workable fontconfig rule that enables antialiasing only for specific fonts at certain sizes. i’m not sure it’s even possible to set such a rule, despite putting together well-formed XML to do just that.

* * *

to sum up: font management on linux can be needlessly complicated, even if you don’t have special vision needs. my environment is overall a bit better, but i’m not ready to move entirely to antialiased text, not until it’s less blurry. i need crispy, sharp text.

fonts on my android phone’s screen look pretty good despite the antialiasing used everywhere, but the thing’s pixel density is so much higher than laptop and desktop LCDs that the display server doesn’t need to resort to complicated smoothing/hinting techniques to achieve that look.

as a general resource, the arch linux wiki page has very useful information on font configuration. there are some great ideas in there, even if they don’t all work on my system. the gentoo linux wiki page on fontconfig is a more basic; i didn’t use anything from it.

Moving from Unique to GtkApplication

A new class has been introduced in GTK+3 that is GtkApplication, and GApplication with GIO 2.28. A common use case is to have a single window present every time the same application or command line is run, that is also known as process uniqueness. This is already possible with Unique that was especially developed for single instance applications. This very basic post will show an example in C with Unique, and also how to do it with GtkApplication, where you will see that GtkApplication makes things even easier.

First of all, the documentation available from the GIO source code doesn't give a concrete example for process uniqueness with GApplication. There are mainly examples about using GApplication with GSimpleAction, that is pretty cool since it lets you easily define actions to run on the primary instance outside of the process, either with the same program or a different one.

Single window with Unique

In the following example, a UniqueApp class is instantiated, then it's checked against another running instance. If not, a window is created and a handle is connected to the UniqueApp object to react on received messages. Otherwise a message is sent, and the existing instance will execute the connected handle and put the window in front.
#include <unique/unique.h>
#include <gtk/gtk.h>

static UniqueResponse
cb_unique_app (UniqueApp *app,
gint command,
UniqueMessageData *message_data,
guint time_,
gpointer user_data)
GtkWidget *window = user_data;
if (command != UNIQUE_ACTIVATE)
gtk_window_present (GTK_WINDOW (window));

gint main (gint argc, gchar *argv[])
GtkWidget *window;
UniqueApp *app;

gtk_init (&argc, &argv);

app = unique_app_new ("info.mmassonnet.UniqueExample", NULL);
if (unique_app_is_running (app))
if (unique_app_send_message (app, UNIQUE_ACTIVATE, NULL) == UNIQUE_RESPONSE_OK)
g_object_unref (app);
return 0;

window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);

gtk_main ();
return 0;

Single window with GtkApplication

In this example, a GtkApplication class is instantiated. This one is then registered, and a check is done to know if the running process is the primary one or a remote one. Just like in the previous example, either the process is the main one and a window is created and shown, otherwise a signal is sent and the connected handle will put the window in front. The handle used here is directly a GTK function that presents the window which spares the need to write a custom handler.
#include <gtk/gtk.h>

gint main (gint argc, gchar *argv[])
GtkWidget *window;
GtkApplication *app;
GError *error = NULL;

gtk_init (&argc, &argv);

app = gtk_application_new ("info.mmassonnet.GtkExample", 0);

g_application_register (G_APPLICATION (app), NULL, &error);
if (error != NULL)
g_warning ("Unable to register GApplication: %s", error->message);
g_error_free (error);
error = NULL;

if (g_application_get_is_remote (G_APPLICATION (app)))
g_application_activate (G_APPLICATION (app));
g_object_unref (app);
return 0;

window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);

g_signal_connect_swapped (app, "activate", G_CALLBACK (gtk_window_present), dialog);

gtk_main ();
return 0;
In both examples there is just one difference, it is how the primary process is seen. With Unique there is a function to know if another instance is running, while with GtkApplication there is a function to know if the current process is not the primary one e.g. a remote instance. I prefer the second approach, since with Unique if there is only one instance running, the is_running property will tell you false but the primary instance is running, isn't it? But anyhow, as you can see, it is possible to implement painlessly what is done by Unique with GtkApplication.

Xfdesktop 4.10.1

I just released Xfdesktop 4.10.1 which contains some bug fixes and updated translations which had been there for months. Congratulations to Eric Koegel who committed most of them!

Amongst others, fixed background cycling and improved menu icons' loading are appreciated.


  • Add a tabs width of padding for tooltip text (Bug #9162).
  • Fix theming of removable devices' icons (Bug #8977).
  • SVG images are no longer pixilated when scaled up.
  • Improve menu icon loading (Bug #8795).
  • Fix background cycling (Bug #8962).
  • Fix a crash when minimized window icons are resized (Bug #8963).
  • Fix use after free error in xfdesktop_regular_file_icon_peek_tooltip (Bug #9059).
  • Translation updates: Arabic, Bulgarian, Croatian, Dutch, Greek, Korean, Polish, Russian, Serbian, Turkish and Uyghur.

Parole 0.4.0 is out!

A new awesome release of the Parole media player for Xfce is out and ships all the hard work of Sean Davis and Simon Steinbeiss.

Sean wrote an extensive description of this new release on his blog, with tons of screenshots. As stated there, do not hesitate to give them feedback on this new release and to file any issue you may have on the Xfce Bugzilla.

Here is a screenshot of the new very nice main view while playing an audio file:

Parole 0.4.0

Congratulations to Sean and Simon for this excellent work!

Xfce4-terminal 0.6.x keyboard shortcuts

A lot of users seem to be wondering how to edit keyboard shortcuts in xfce4-terminal 0.6.x. The built-in shortcut editor is indeed gone and the application now uses editable GTK+ accelerators like other GTK+ applications. This is more consistent and allows to drop the exo dependency which makes the application lighter.

The FAQ of the Xfce documentation has a guide on how to edit GTK+ accelerators of xfce4-terminal. You'll get your custom shortcuts back in no time!

PS: xfce4-terminal 0.6.1 is out and has a killer "drop-down" mode ala guake / tilda. See Nick's Google+ page for screenshots.

Work in progress to improve keyboard shortcuts in Xfce

Long time no blog! I started to hack again last week with the goal of improving keyboard shortcuts handling in Xfce. I touched that during the Xfce 4.10 cycle and this unfortunately seem to have introduced a bunch of bugs that I'm now trying to resolve. I also took this opportunity to try to overhaul the UI and make it more understandable.

This code is available in the jeromeg/keyboard-shortcuts branches of xfwm4, libxfce4ui and xfce4-settings on the Xfce Git server. Some improvements are still planned but most of what I was planning is already implemented.

Here is a list of reported bugs which should be fixed once I merge this:

A brief summary: shortcuts now work when Caps Lock is on, shortcuts using Shift or the numeric keypad are handled correctly, a bunch of regressions are fixed, conflict handling is now more reliable and the UI should be better.

Regarding keyboard shortcuts bugs, keyboard shortcuts not working correctly after a reboot or not work working in some other cases seem to occur because of a "wrong" shortcut database often caused by a problem in the migration script in Xfce 4.6. In that case, the easier way to fix this seems to be to revert all keyboard shortcuts to default (in xfwm4-settings and xfce4-keyboard-settings) and to rebind them using the dialogs.


Readable shortcut labels in the UI

Shortcuts view with now with readable labels

Improved dialogs to add and edit shortcuts

Set shortcut command

Set shortcut keys

Improved conflict handling


Testing is welcome!

If you know what you are doing, it would be useful if you could test those changes and report me by mail any remaining issues. Suggestions for improvements are also welcome.

How to start contributing to Xfce or any other open source project

It’s been a while since I’ve updated this website and even longer since I’ve written anything useful. But since I’ve received a couple of mails from people looking to contribute to Xfce recently, I thought I’d share some “wisdom” acquired over the past few years while working on Xfce and doing a lot of community work. My thoughts are not limited to Xfce and will apply to a lot of other projects out there as well.

Here’s the bitter truth for those looking for some quick pointers to start contributing to Xfce: you’ll have to find out yourself.

The reason is not that we are lazy or wouldn’t welcome your contributions. In fact, the reason, I believe, is very simple: you will be more excited, motivated and, ultimate, be more successful if you work on something that interests you. We can help you in making the decision what to invest your time in easier, e.g. by listing projects, features or issues that we or our users consider worth working on. Some projects do this very visibly (e.g. through bounties). In Xfce, this information is hidden in the depths of the wiki. Here are a few links that you may find interesting:

Clearly, the above information could be more visible. There could be a prominent link on the Xfce website to a well-maintained and up-to-date list. Would that help people? Maybe.

Perhaps it is a good thing that the information isn’t just one click away. Open source projects have always been about scratching your own itch. This is how I got involved in everything I’ve done over the years. this approach is reflected by what people do and sometimes even by how companies make money. Thinking about it now, it is a concept deeply rooted in the evolution of mankind (think: the invention and improvement of tools, industrialisation and all that shit).

So: scratch your own itch.

If you want to start contributing to a project, try this exercise:

  • Look at the project, think about what you don’t like or what you feel could be improved
  • Try to collect information on what pieces are involved in e.g. the feature you’re missing or the bug you’ve spotted
  • Try to find the place where you could try adding your feature or fixing your bug
  • Ask whether developers are interested in the feature or look at whether there already is an item for your issue in the bug tracker
  • The rest is communication and coding

It’s not a fast path because you might not be able to contribute something of great value in the beginning. But if you’re dedicated, have enough spare time to make a difference and are keen on improving things step by step, you might eventually reach a point where you take over responsibility for more and more exciting or important tasks.

Good luck!

Vim and Vala

I once wrote a quick note about Vala and Vim (or Vim and Vala) and the use of the Tag List plugin. Here is a clean post about these two beasts.

Vim — probably the best editor out there, at least always after trying out different editors I end up with Vim — has great plugins. However there is a lack of support for the Vala language. So here are two basic add-ins to include in the Vim editor.

Vala syntax

First there is no syntax color for this language. A quick fix is to use the C# syntax with the command :set filetype=cs. That works but is not ideal, ideal is to install a vim.syntax file, and there is one available on this GNOME Live! page.

First download the file from this page and save it under ~/.vim/syntax. Next at the following lines to your ~/.vimrc file:
" Filetypes
augroup filetypedetect
au! BufRead,BufNewFile *.vala,*.vapi setfiletype vala
augroup END

augroup vala
autocmd BufRead *.vala,*.vapi set tw=100 efm=%f:%1.%c-%[%^:]%#:\ %t%[%^:]%#:\ %m
augroup END

Tag List

Tag List is a powerful plugin that lets you explore classes or functions from a source file, also called a source code browser. The installation steps are simple, they are also available bellow, and again to get it working with Vim there is a small hack to include inside the ~/.vimrc file.

First download the latest version of taglist from this page. Than uncompress the archive with, for example, the command line:
unzip -x -d $HOME/.vim/
Than go inside ~/.vim/doc, run Vim and inside Vim execute the command :helptags .:
cd ~/.vim/doc
:helptags .
Finally add the following lines inside ~/.vimrc:
" Work-around Tag List for Vala
let tlist_vala_settings='c#;d:macro;t:typedef;n:namespace;c:class;'.
\ 'E:event;g:enum;s:struct;i:interface;'.
\ 'p:properties;m:method'

Now Vim is ready for Vala, and it's possible to browse source code by typing the command :TListToggle.

Screenshot of Vim Vala Tag List
Vim Vala Tag List

Questions after the 4.10 release

A short post to answerer some questions I’ve ready in comments on the 4.10 release news across the internet. If you have more questions, let me know in the comments and I’ll try to answer them.

A new stable release after 16 months? And no 4.8.1 release…

This is because Xfce has a different release model than for example GNOME or KDE when it comes to stable releases. Because of the limited team of developers we want to spend the least time possible on releasing packages. Big stable releases like other desktops do consume a lot of time, even with the small-ish amount of core packages in Xfce.

Therefore after 4.6 the following was decided: we only do 4 big releases (3 preview releases and 1 stable release) and after that only stable releases for individual packages. So the desktop version is 4.10 (notice the lacking micro-number), individual components could have higher 4.10.x numbers.

As an example, the last 4.8 stable release of xfce4-dev-tools is 4.8.0, the same as in the 4.8 fat-tarball release. The latest 4.8 release of xfce4-panel is 4.8.6 (6 stable releases after 4.8.0, which was in the 4.8 fat-tarball).

We know this is harder for starting users, who prefer to grab 1 tarball with all the latest versions, but instead need to crawl through /src/xfce and need to find the latest version. For distributions this is a lot easier: packagers are subscribed to the xfce-announce mailing list or peek and once in a while they need to update 1 of the packages.

Nonetheless this is still a point where we can improve so I’ll see if I can provide more information on the website (announcements and links to the latest package versions).

4.10 only had 2 preview releases, because no critical bugs appeared and translations were in a good shape. Enough reasons for me to skip pre3 and release 4.10 instead.

Online Documentation Wiki

Just to be clear about this: we understand online docs are not a solution, but it was the best we could do in a short time. Hopefully the wiki-based setup will attract more contributors (who previously feared docbook or mallard, yes we tried that too) and lead to a complete set of documentation . When we feel satisfied with the content of the wiki we’ll look into a “wiki snapshot” for offline usage and ship that in an xfce4-docs package.


First 2 things: no Xfce 4.10 is not using gtk3, only the gtk-xfce-engine theme engine supports gtk3. Secondly we will discuss if Xfce 4.12 will be ported to gtk3. I’ll explain the latter:

Technically gtk3 is nothing different then gtk2 when it comes to programming. The hard parts are porting of some custom widgets (drawing and size allocation), replacements of some deprecated symbols and link to gtk3 libs. All things a user is not going to notice if we do it right.

Gtk3 is also not faster than gtk2, maybe there are some areas were it got a bit faster, but so there are areas where performance decreased a bit. Nothing shocking here.

An issue I’m aware of is theming issues in gtk3. From what I understand this changed back and forward in gtk 3.0, 3.2 and 3.4. So we need to decide which version we require to get this working consistently, because people will complain if only the Raleigh theme can be used :).

From the Xfce point of view there is (again) the resource problem for porting all plugins, because if for example the panel is ported to gtk3, also the plugins need to be ported. Not all goodies are maintained, but usually they work and distros can compile them. If in 4.12 suddenly 50% of the external plugins are not working that will be another thing users will notice.

At any rate, don’t get overly excited about gtk3, it’s just gtk 2.26 with a huge api break :). Once we decided which version we use in 4.12, I’ll post it on the blog.

LXDE still consumes less memory

*sigh* I’m not going to rant on this because as a user you should choose the desktop that makes you happy, but anyway it annoys me a tiny bit. So just to throw some information:

LXDE and Xfce are both based on the same toolkit and provide roughly the same set of features. That as a start makes it technically almost impossible to be much better or worse regarding memory usage. I think this whole myth started by comparing two distributions (clue: strcmp (distro_a + 1, distro_b + 1) == 0).

I’m sure Xfce consumes a bit more memory, because more processes are started. Especially when external plugins are added to the panel: a design decision to make the panel more stable.

I don’t know or care where this comparison started, but if somebody does this again the the future, please compare the actual memory usage and don’t use free. Or even better: don’t compare memory usage at all because it is pretty useless.
That said: if I start a default LXDE and Xfce 4.10 desktop (default Arch Linux packages) and use, Xfce consumes 2 MiB more memory (same or desktop-equal applications are started). Do whatever you want this is number, as long as you compare apples and apples.

Not much accomplished in over 1 year

Sorry, I also work the entire week. But I don’t blame myself, Xfce is a fun project for all of us and if people move to another country, have a day job, a life, school/exams or simply don’t feel like working on Xfce not much progress is made.

Personally I don’t have the feeling not much was done in 4.10, we didn’t break anything major and a lot of the todo’s for 4.10 were completed in the release cycle. The focus was polishing and that’s what we did!


  • 01-05 13:34: Added “Not much accomplished in over 1 year”.