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)
{
return UNIQUE_RESPONSE_PASSTHROUGH;
}
gtk_window_present (GTK_WINDOW (window));
return UNIQUE_RESPONSE_OK;
}

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.

Changelog

  • 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.

Keyboard shortcut work landed

After a few user interface improvements and some last bug fixes, the work I described in my last post was merged in the master branches. It is thus available for testing to all users of the Xfce development version.

Feedback on this is welcome, file any bug you find on the Xfce Bugzilla. This will of course be available in the next development release of those components.

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.

Screenshots

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

conflict-dialog.png

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.

Apache restart with Vim autocmd

In order to execute a command right after saving a file in Vim, you can use the :autocmd command. Here is a quick example how it can be useful with Apache files.

NB: on my system, Debian in this case, an Apache file is automatically recognized as filetype=apache.

augroup apache
autocmd BufWritePost */sites-enabled/* !/etc/init.d/apache2 restart
augroup END

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!

Google TV and Native Libraries

The Google TV runs a fairly unusual flavor of Android (at least the 2nd-gen ARM-based devices). I have a Sony Internet Player (not the Blu-Ray version), so what I'm about to write applies to that device, but maybe not any other, though it stands to reason that the other ARM-based GTVs are the same.

Phone-and-tablet Android doesn't look much like a Linux desktop or server system. It uses the Linux kernel, to be sure, but a lot of the userspace libraries are custom. It even does not use Glibc, but a C library that Google wrote called Bionic. It's fairly stripped down and lightweight, and while it implements most things you might need out of a standard libc, it does not pretend to be POSIX compliant.

From some simple investigation, I've learned that the Sony GTV is running a EGlibc 2.12.2, and probably a mostly-unmodified version of it. Someone with an @google.com email address stated that the reason for this was that they couldn't get Chrome running against the Honeycomb version of Bionic.

Due to this, a Native Development Kit (NDK) is not yet available for the GTV. So the question remains: can we hack one together that works? The answer is... sorta.

With this knowledge in hand, I built a relatively standard arm-linux-gnueabi toolchain using crosstool-ng. Then I 'adb pull'-ed the contents of /system/lib from my GTV and merged them with the new toolchain's sysroot, copied some headers out of a stock NDK, and ended up with a sysroot that approximates what you'd find in platforms/ in a stock NDK, just without Bionic, and with EGlibc.

I didn't get to modifying the NDK's build system (it would need to be changed to find the new toolchain), so I built my native library manually, and got a simple "hello world" type app with a native lib. (It just calls a native method that returns a string, and displays the string on a label.)

One annoying thing is that the ABI string in the Sony GTV is set to "none", so you have to unpack the APK, rename lib/armeabi-v7a/ to lib/none/, and repack and resign it. All of this means that this would be strictly hobbyist for now: no chance that you could distribute something in the Play Store. Not only does Google have to release an officially-working NDK, but they need to decide on an ABI string, and get Sony (etc.) to push updates out to their customers that update build.prop on the devices with the new ABI string.

There's also the possibility that Google doesn't want to create and officially support that much native drift between phone-and-tablet Android and GTV Android, and will wait until manufacturers are running a more-stock Android 4.x on GTV (that uses the 4.x version of Bionic) before releasing an NDK that works... in which case we're at the mercy of Sony for updates, unless XDA or CyanogenMod wants to take a crack at it. My money's on this scenario, unfortunately.

One of the main things people have been screaming for is a version of XBMC that runs on GTV. I have been able to get it to build using my hacked-together toolchain, but not actually to run. I ran into problems with runtime linking: the built binaries depend on a shared libstdc++ and libgcc_s, neither of which appear to be included on the GTV's filesystem. I tried including them in the APK, but, weirdly, when the GTV unpacks the native libs from the APK at install time, it discards those two libraries. Static linking of those two may not be possible since XBMC's APK includes a bunch of native libs. A possible solution would be to build all of libxbmc.so's dependencies as static libs, and then just make one big static library.

But I haven't had time to work on this over the past couple weeks...