Making use of custom actions with Xfce Appfinder

One addition in the latest versions of Appfinder was the custom actions. I never used it until after I started typing several times twitter which didn't work (a habit from the web browser url bar).

The custom actions can be useful for anything, and it's really quick to run it.

Examples of custom actions:

• twitter: xdg-open https://twitter.com/
• us: setxkbmap us

It can be very handy, check the online documention for a quick setup. There are also online examples, don't mind to leave a comment or to fill the bugtracker if you have clever ideas, I can add them, I just did with the setxkbmap us example ;-)

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.

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 vala.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 add 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 Vala there is a small hack to include inside the ~/.vimrc file.

First download the latest version of taglist from this page. Then uncompress the archive with, for example, the command line:

unzip -x taglist_45.zip -d $HOME/.vim/

Then go inside ~/.vim/doc, run Vim and inside Vim execute the command :helptags .:

cd ~/.vim/doc
vim
: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.

Vim Vala Tag List

Xfce 4.8 with Conky

I have been following a short discussion on the IRC channel #xfce regarding an issue with the use of Conky and transparency. I didn't use Conky for a very long time, but since I knew it was possible to have Conky perfectly running, I gave it a shot again and since I did a fresh reinitialization of Xfce on my workstation, I tweaked the configuration file to my need. Now I have it running in the background and I'll most probably keep it.

The configuration I was able to get for a good working Conky window with transparency is bellow. Of course I could tell you which combination doesn't work, with the why, but since there are so many of them I simply put a working one.

own_window yes # create a separate XWindow over the one from Xfdesktop
own_window_type desktop # the window cannot be moved or resized
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager # make it behave like it belongs to the desktop
own_window_argb_visual yes # true transparency, a compositor has to be active
own_window_argb_value 100 # make the background semi-transparent
double_buffer yes # avoid flickering

Here is a screenshot of the desktop with Conky in the bottom right corner, I made sure there is some I/O activity going on :-)

Xfce with Conky

Now if you want you can steal my .conkyrc file.

Changing PolicyKit settings per user

I have been hit twice by a required authentication on my workstation after the Wifi connection got lost and it is clearly irritating, especially when you are not around. The authentication requests are handled by PolicyKit (polkit for short) and can be tweaked.

The message by which I was hit was the following: "System policy prevents modification of network settings for all users."

Before you get started, the system wide configuration files that contain the default values reside inside the /usr/share/polkit-1/actions/ directory. In this directory resides the file org.freedesktop.NetworkManager.policy which contains all the default actions. It does also contain the message about the network settings for which the action id is "org.freedesktop.NetworkManager.settings.modify.system." At this point I was still clueless of what I was supposed to do.

After having search the web for information about PolicyKit I have found one interesting article that helped me getting done with my issue and learning more about this authorization framework. This action being very seldom to perform, I'm summing up everything here.

There are two useful commands to perform tests with PolicyKit, pkcheck and pkaction.

The first interesting command to use is pkcheck. It will trigger an authorization request and prompt you to type in a password, simply return true if no authorization is required otherwise false. For example:

pkcheck --action-id org.freedesktop.NetworkManager.settings.modify.system \
    --process `pidof gnome-session` -u `id -u`

You have to adapt the process and user parameters of course.

Next the command pkaction can be used to print the default system values, for example:

pkaction --action-id org.freedesktop.NetworkManager.settings.modify.system \
    --verbose

Now to have a custom setting for your user, what has to be done is to create a PolicyKit Local Authority file inside the directory /var/lib/polkit-1/localauthority/. Here is an example:

[Let user mike modify system settings for network]
Identity=unix-user:mike
Action=org.freedesktop.NetworkManager.settings.modify.system
ResultAny=no
ResultInactive=no
ResultActive=yes

I have saved this file under /var/lib/polkit-1/localauthority/50-local.d/10-network-manager.pkla.

There are three main values you can pass to ResultActive that are no, auth_admin or yes. Respectively it will deny the authorization, ask for a password, and give access. For further information about the possible values check the polkit manpage, also don't miss the pklocalauthority manpage to read more about the localauthority tree structure.

XTerm as root-tail

The idea behind this title is to use XTerm as a log viewer over the desktop, just like root-tail works. The tool root-tail paints text on the root window by default or any other XWindow when used with the -id parameter.

Using XTerm comes with little advantage, it is possible to scroll into the “backlog” and make text selections. On a downside, it won't let you click through into the desktop, therefore it is rather useful for people without desktop icons for example.

We will proceed with a first simple example, by writing a Shell script that will use the combo DevilsPie and XTerm. The terminals will all be kept in the background below other windows and never take the focus thanks to DevilsPie. DevilsPie is a tool watching the creation of new windows and applies special rules over them.

Obviously, you need to install the command line tool devilspie. It's a command to run in the background as a daemon. Configuration files with a .ds extensions contain matches for windows and rules that are put within the ~/.devilspie directory.

First example

The first example shows how to match only one specific XTerm window.

The DevilsPie configuration:

DesktopLog.ds

(if
 (is (window_class) "DesktopLog")
 (begin
  (wintype "dock")
  (geometry "+20+45")
  (below)
  (undecorate)
  (skip_pager)
  (opacity 80)
 )
)

The Shell script making sure devilspie is running, and spawning a single xterm process:

desktop-log.sh

#!/bin/sh
test `pidof devilspie` || devilspie &
xterm -geometry 164x73 -uc -class DesktopLog -T daemon.log -e sudo tail -f /var/log/daemon.log &

NB: You can notice the size of the XTerm window is set through the Shell script while the position is set through the DevilsPie rules file, and there is a simple reason for this. By default XTerm has a size of 80 columns and 24 lines and text with too long lines will be wrapped on the next line. If afterwards you resize the window the wrapped text won't move up and the result will be ugly. Therefore it's better to set the initial size of the terminal correctly.

To try the example, save the DevilsPie snippet inside the directory ~/.devilspie, and download and execute the Shell script. Make sure to quit any previous DevilsPie process whenever you modify or install a new .ds file.

Second example

The second example is a little more complete, it starts three terminals of which one is coloured in black.

DesktopLog.ds

(if
 (matches (window_class) "DesktopLog[0-9]+")
 (begin
  (wintype "dock")
  (below)
  (undecorate)
  (skip_pager)
  (opacity 80)
 )
)
 
(if
 (is (window_class) "DesktopLog1")
 (geometry "+480+20")
)
 
(if
 (is (window_class) "DesktopLog2")
 (geometry "+20+20")
)
 
(if
 (is (window_class) "DesktopLog3")
 (geometry "+20+330")
)

desktop-log.sh

#!/bin/sh
test `pidof devilspie` || devilspie &
xterm -geometry 88x40 -uc -class DesktopLog1 -T daemon.log -e sudo -s tail -f /var/log/daemon.log &
xterm -geometry 70x20 -uc -class DesktopLog2 -T auth.log -e sudo -s tail -f /var/log/auth.log &
xterm -fg grey -bg black -geometry 70x16 -uc -class DesktopLog3 -T pacman.log -e sudo -s tail -f /var/log/pacman.log &

NB: You will probably notice that setting the geometry is awkward, specially since position and size are in two different files, getting it right needs several tweakings.

This blog post was cross-posted to the Xfce Wiki.

CLI tool to review PO files

If there is something annoying about reviewing PO files is that it is impossible. When there are two hundred messages in a PO file, how are you going to know which messages changed? Well, that's the way it works currently for Transifex but there are very good news, first a review board is already available which is a good step forward but second it is going to get some good kick to make it awesome. But until this happens, I have written two scripts to make such a review.

A shell script msgdiff.sh

Pros: tools available on every system
Cons: ugly output, needs template file

#!/bin/sh
PO_ORIG=$1
PO_REVIEW=$2
PO_TEMPL=$3

MSGMERGE=msgmerge
DIFF=diff
PAGER=more
RM=/bin/rm
MKTEMP=mktemp

# Usage
if test "$1" = "" -o "$2" = "" -o "$3" = ""; then
    echo Usage: $0 orig.po review.po template.pot
    exit 1
fi

# Merge
TMP_ORIG=`$MKTEMP po-orig.XXX`
TMP_REVIEW=`$MKTEMP po-review.XXX`
$MSGMERGE $PO_ORIG $PO_TEMPL > $TMP_ORIG 2> /dev/null
$MSGMERGE $PO_REVIEW $PO_TEMPL > $TMP_REVIEW 2> /dev/null

# Diff
$DIFF -u $TMP_ORIG $TMP_REVIEW | $PAGER

# Clean up files
$RM $TMP_ORIG $TMP_REVIEW

Example:

$ ./msgdiff.sh fr.po fr.review.po thunar.pot
[...]
 #: ../thunar-vcs-plugin/tvp-git-action.c:265
-#, fuzzy
 msgid "Menu|Bisect"
-msgstr "Différences détaillées"
+msgstr "Menu|Couper en deux"
 
 #: ../thunar-vcs-plugin/tvp-git-action.c:265
 msgid "Bisect"
-msgstr ""
+msgstr "Couper en deux"
[...]

A Python script podiff.py

Pros: programmable output

Cons: external dependency

The script depends on polib that can be installed with the setuptools scripts. Make sure setuptools is installed and than run the command sudo easy_install polib.

#!/usr/bin/env python
import polib

def podiff(path_po_orig, path_po_review):
    po_orig = polib.pofile(path_po_orig)
    po_review = polib.pofile(path_po_review)
    po_diff = polib.POFile()
    po_diff.header = "PO Diff Header"
    for entry in po_review:
        orig_entry = po_orig.find(entry.msgid)
        if not entry.obsolete and (orig_entry.msgstr != entry.msgstr \
        or ("fuzzy" in orig_entry.flags) != ("fuzzy" in entry.flags)):
            po_diff.append(entry)
    return po_diff


if __name__ == "__main__":
    import sys
    import os.path

    # Usage
    if len(sys.argv) != 3 \
      or not os.path.isfile(sys.argv[1]) \
      or not os.path.isfile(sys.argv[2]):
        print "Usage: %s orig.po review.po" % sys.argv[0]
        sys.exit(1)

    # Retrieve diff
    path_po_orig = sys.argv[1]
    path_po_review = sys.argv[2]
    po_diff = podiff(path_po_orig, path_po_review)

    # Print out orig v. review messages
    po = polib.pofile(path_po_orig)
    for entry in po_diff:
        orig_entry = po.find(entry.msgid)
        orig_fuzzy = review_fuzzy = "fuzzy"
        if "fuzzy" not in orig_entry.flags:
            orig_fuzzy = "not fuzzy"
        if "fuzzy" not in entry.flags:
            review_fuzzy = "not fuzzy"
        print "'%s' was %s is %s\n\tOriginal => '%s'\n\tReviewed => '%s'\n" % (entry.msgid, orig_fuzzy, review_fuzzy, orig_entry.msgstr, entry.msgstr)

Example:

$ ./podiff.py fr.po fr.review.po
'Menu|Bisect' was fuzzy is not fuzzy
 Original => 'Différences détaillées'
 Reviewed => 'Menu|Couper en deux'

'Bisect' was not fuzzy is not fuzzy
 Original => ''
 Reviewed => 'Couper en deux'
[...]

Don't produce Gzipped tarballs

A quick note so I can delete it from my desktop. In order to produce only a Bzip2 tarball with the Autotools, specially when running make distcheck, set the automake init call with these parameters:

AM_INIT_AUTOMAKE([no-dist-gzip dist-bzip2])

By the way I wonder if it's worth dumping bzip2 against xz.

Major changes in the Xfce Task Manager going 1.0

It's done. The task manager application available in Xfce for quite some years is now available with major changes. It has been rewritten from scratch, with GtkBuilder UI definitions and GObjects, everything is fresh and clean. The application has support for Linux, OpenBSD, FreeBSD and OpenSolaris.

Let's start by visual changes:

• The buttons at the bottom are gone, the progress bars at the top are vanished, say hello to a toolbar with buttons and monitors.
• You read well, monitors are in, they show a graph of the CPU and memory usage by time.
• A status bar is visible at the bottom, it displays a general information about the system usage.
• Icons are displayed beneath the task names.

Let's continue with less visual:

• Tasks that start are displayed with a green background for a short delay and tasks that terminate with a red background.
• Tasks which state is changing are temporarily displayed with a yellow background. This covers tasks changing their state from idle to running, vice versa and etc.
• The tree views context menu contains the same actions as before, sending signals to the task and changing the priority. They have been polished however, for example the continue and stop signals aren't shown altogether anymore, and there are only five priorities to set ranging from Very low to Very high.
• The tree view columns can be reordered as you wish.
• An optional status icon can be activated allowing you to hide the application.
• It is possible to display percentage values with more precision.
• And finally, the default refresh rate is 750ms and it can be switched from 500ms up to 10s.

And the result is as follows:

The application is fully translated into fifteen languages!

Go to project webpage.

New notes plugin release 1.7.3

Three months since the last release, and three months since it is available as a separate standalone application running in the notification area. This has made it a lot easier to test and debug, as before I had to build the plugin, install the plugin, restart the panel or remove/readd the plugin in the panel, now I just have to run ./xfce4-notes from the source directory.

This new release has seen some structural tree changes to save time during compilation. Now everything is in src/ and lib/, where lib/ contains code to build an XnpHypertextView, an XnpNote (a composite-widget that embeds a GtkScrolledWindow with an XnpHypertextView and sends “save” signals on changes), an XnpWindow with the custom made navigation and title bars and the right click menu on the title bar, and finally an XnpApplication class that is the heart of everything, it handles creations/deletions of notes, loads/saves the data, etc. The src/ directory contains the main files for the panel plugin, the status icon, the popup command and the settings dialogue.

The new stuff is mostly eye-candy as stated in the previous blog entry. The GTK+ RC style has been pimped up with custom made scrollbars and the source code contains a self-drawn close button. The stuff about GTK+ scrollbars theming is grossly explained on live.gnome.org but I opened the GTK+ Dust theme files which was, to me, more understandable :-) Also it was because of this particular theme I took a look at customizing the scrollbars, see below the before/after screenshots. The older article about writing a Widget with Cairo helped me getting started from scratch with an empty “close button” widget to replace the simple GtkButton with label. As I liked very much the time passed on these changes I contributed a tutorial “Monochrome icon” available only in PDF as of today which I hope to be useful for Vala beginners but also a nice update of the article about Cairo but with Vala language.

The fixes included in this release are the following: correctly restore sticky-window and keep-above states after some race conditions, and restore tab label orientation after renaming a note. And last but definitely not least the undo feature was not working because an internal timeout wasn't reset to zero which made the code think a snapshot was needed and thus the undo/redo buffers ended with the same content after the timeout elapsed. Thanks to Christian (the developer behind Midori) otherwise I would still not have taken a look around this!

The forthcoming features I have in mind would be a search dialogue and per-note options for activating a stripped down “markdown” syntax, an orthographic corrector and wrapping words which is the default for the moment.

The release is available at archive.xfce.org.

Thanks for the feedbacks and reports you sent and will send back.

Update: The tutorial is now also available on the Xfce wiki.

Include custom GTK+ RC style

I've been using a custom GTK+ RC style for the notes plugin since the version 1.4.0, right now it is at version 1.7.2. I have been playing with GTK+ theming again these last two hours, and I've get custom scrollbars, a gradient for the custom-made “title bar”, and better colours for the notebook to get the current tab stand out from the crowd.

While experimenting on a test-case code I found out a better way to parse a gtkrc file in the program. The first time I was fighting with the existing gtk_rc related functions, I gave up on a solution I partially dislike that is to include a line to the custom gtkrc file within ~/.gtkrc-2.0.

Today I understood how gtk_rc_parse(filename) behaves. You have to call this function at the beginning of the program before building any widgets, it will work even if the file doesn't exist yet. Next, while the program is running, you can modify the file, create it, delete it, truncate it, whatever, and call gtk_rc_reparse_all() to get the style refreshed in the GUI. It's hard to believe that such easy things are sometimes a PITA :-)

Be prepared for a 1.7.3 notes plugin with nicer colours.

Show/hide functionality from notification area

When using a status icon within the notification area it is common to use the left-click action to show/hide the main window. Obviously this is often done in different ways. So here is my tip on how to do it right :-)

What I believe to me the most sense-full way is to:

1. Check if the application is invisible and show it,
2. Otherwise check if the window is inactive and present it,
3. Otherwise hide it.

In C language it looks like this:

/* Show the window */
if (!(GTK_WIDGET_VISIBLE(window))) {
    gtk_widget_show(window);
}
/* Present the window */
else if (!gtk_window_is_active(GTK_WINDOW(window))) {
    gtk_window_present(GTK_WINDOW(window));
}
/* Hide the window */
else {
    int winx, winy;
    gtk_window_get_position(GTK_WINDOW(window), &winx, &winy);
    gtk_widget_hide(window);
    gtk_window_move(GTK_WINDOW(window), winx, winy);
}

I have been doing this for quite a long time inside the Xfce Notes plugin, except a little different with multiple windows.

Some remarks, the PendingSealings proposes gtk_widget_get_visible instead of its analogous MACRO. And as you may also notice when the window is hidden it gets moved just after, this is important as otherwise the window would be repositioned by its initial value once shown again (e.g. centre of screen or dynamically by the window manager).

The download manager is in the wild

So it's finally done, it took very long, but it's done. The download manager I once had in mind is taking off into the wildness :-) Of course it took long because I never did something with it, writing a front-end to wget/curl isn't interesting -- who cares about downloading HTTP/FTP files when the web browser handles it for you anyway -- and reusing GVFS doesn't make sense cause really you don't want to download from your trash:// or whatever proto:// and again only HTTP/FTP is not interesting. Not at all. I have come across Uget and other very good projects but most of them are either writing the code to handle the protocol like HTTP and/or are looking forward to handle more interesting protocols like BitTorrent. I think it's a very tough job that demands too much for a one-maintainer project. Recently I saw the new release of aria2 that comes with an XML-RPC interface and this took all my interest during 4 days. I believe this utility is very promising and I had really like to write the good and user-friendly XML-RPC GUI client that it seems to be missing!

What is so exciting about aria2? In case you know the project you don't have to read, but it is worth mentionning the features of this small utility. It supports HTTP(s)/FTP but also BitTorrent and Metalinks. It is widely customizable for each specific protocol. It can download one file by splitting it into several pieces and using multiple connections and even mix HTTP URIs with BitTorrent and by the same time upload to BitTorrent peers what has been downloaded through HTTP. So this has to be the perfect candidate to write a nice download manager, hasn't it?

The client is a very first version that I intended to code name draft although the release assistant on xfce.org doesn't allow this. Instead it will take the more neutral road of 0.1.0 to 0.1.1 etc until 0.2.0 followed by stable fix releases.

Why draft? Simple. It's being written with a higher level language than C but not even Vala :-) High-level languages are a great deal when starting a new application, as you can type more and get more, instead of typing like a dog for a rocking hot, well lousy, window. Since I do like Ruby, it's being written in Ruby currently, and it depends on the ruby-gnome2 project for the bindings. To get a picture, a main file to open a window takes 3 lines. Of course the final version is meant to be written in Vala/C, but I still need to convince myself that Vala+libsoup isn't an option that is going to waste too much time. Also at first glance libsoup looks easy to use, it allows to build XML-RPC requests, to request the HTTP bodies and to send messages, but it is not an XML-RPC client and you never know how well the Vala bindings will play. This means extra attention for small things. Starting an application from scratch with such constraints are usually a big time-killer therefore using like in this case an existing XML-RPC client is very important. The GUI is done with Glade in GtkBuilder format and reusing it into a new language will be pretty easy.


So what's next? I'll just wait for some feedback see what the audience thinks about it, if at all, and polish here and there. Keep tuned for the next update.

Messing up with Vala (again)

First some good news. I didn't look close enough into the possibilities offered by Automake 1.11 when I first wrote the post about building Vala projects. Automake 1.11 is all about making releases without the end-users having to compile Vala! Just like it is written in the Automake documentation. From now on I will always apply this wherever it is possible.

I updated the Xfce4 Vala bindings with libraries from the 4.7 stack. In there I have updated the panel plugin example, and as you can see the Automake file is extremely short. When there is a SOURCES defined with a Vala file, Automake will create targets for each compiled program or library with Vala compilation, and generate one vala.stamp file per target. This has its pros and cons. In the case of the Notes plugin, this disallowed me to have a mix of only C written software and Vala inside the same directory. In reality I used to have a single main file for the panel plugin to compile to C either for the 4.7 version or prior. Automake makes the Vala specific targets visible outside the scope of the "if PANEL47 ... else ... end" block. I ended up with self-compiled Vala for each target in maintainer mode only, as previously, which is a small overhead for the specific targets.

Other nice thing about Vala is that bindings are just files. I compiled the Notes plugin for the Xfce 4.6 panel on my netbook just to verify everything is alright but unfortunately there were some problems. I bumped the required version of Vala to 0.7.8 which has GTK+ bindings for 2.18 already while I only have GTK+ 2.16 available. The simple thing to do was to download the GTK+ bindings from the version of Vala I used previously and copy them into a location of the project (or system wide).  As long as the Vala compiler knows where to pick them up (with "--vapidir=") it will choose them and not the ones provided by default. This makes it awesomely easy to provide customized bindings for example.

Vala can always be very time consuming, but I still like it! Just like git merge by the way.

Build a project with Vala

This post is about using Vala in a project but in the end provide the C code for the releases. I think that this is very essential and that releasing source code to be build from Vala is wrong. Vala will always rewrite the code to GObjects in C, but has already proven that compiling the same code from two different versions of Vala will fail. So when you are doing releases with Vala you will break your releases sooner or later. Another good point is when the Vala code is compiled on top of patched vapi files, doing only C compilation with the releases will drop the requirement to apply them.

I'll take as example the Autotools, if you are using a different tool-chain you can surely adapt it. The idea is simple, the Vala sources are only compiled in maintainer mode. When you compile the application from the development branch you will usually have a script called autogen.sh to build the configure script that will automatically be executed with the parameter --enable-maintainer-mode. When providing the distribution tarball that is created with make distcheck, the configure script will not be run with that parameter (except if specified by hand) and the source files to build from will be filled in with the C filenames.

The example below is very generic and can be copy/pasted but should be adapted.

Autoconf script

1. The initialization of Automake and the maintainer mode in the autoconf script. The Automake version is checked for 1.11 which is the first version that comes with Vala support. The extra dist-bzip2 argument is there to provide an extra bzipped distribution tarball as you guessed it.

AM_INIT_AUTOMAKE([1.11 dist-bzip2])
AM_MAINTAINER_MODE()

2. The check for Vala only on maintainer mode. The AM_PROG_VALAC defines the variable VALAC that can be reused inside the Makefile.am files and accepts an optional version check.

if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
  AM_PROG_VALAC([0.7.4])
  if test "x$VALAC" = "x" ; then
      AC_MSG_ERROR([Cannot find the "valac" compiler in your PATH])
  fi
fi

3. It is possible to sum up the build configuration at the end of the autoconf script.

echo
echo "Build Configuration:"
echo
echo "* Maintainer Mode:        $USE_MAINTAINER_MODE"
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
echo
echo "    * Vala:               $VALAC"
echo
fi

Automake script

1. The declaration of the Vala sources and their respective compiled C sources.

product_VALASOURCES = \
  obj1.vala \
  obj2.vala \
  main.vala

product_VALABUILTSOURCES = $(product_VALASOURCES:.vala=.c) product.h

2. Use the special BUILT_SOURCES variable to build given targets before running a dist with e.g. make distcheck. This usually done in maintainer mode, as in this case to be sure the releases won't have anything to do with Vala.

if MAINTAINER_MODE
PACKAGES = --pkg=gtk+-2.0
BUILT_SOURCES = vala.stamp
vala.stamp: $(product_VALASOURCES)
  $(VALAC) --vapidir=$(srcdir) $(PACKAGES) $^ -C -H product.h
  touch $@
endif

3. The final sources for the product are filled in with the generated Vala sources. The Vala sources are not passed to any SOURCES which is why they are passed to the special EXTRA_DIST variable.

product_SOURCES = \
  random-source.c \
  random-header.h \
  $(product_VALABUILTSOURCES)

EXTRA_DIST = $(product_VALASOURCES)
if MAINTAINER_MODE
CLEANFILES = \
  $(BUILT_SOURCES) \
  $(product_VALABUILTSOURCES)
endif

That's it

There are many existent Vala projects nowadays from where you can pick up new ideas, and this post is just an example amongst many others. The full example is available in the xfce4-vala bindings.

Update: I corrected some mistakes seen in green in the script portions. If VALAC is unset the configure script must quit otherwise the resulting Makefiles will have empty commands instead of /usr/bin/valac. Also the generated header file must be passed to product_VALABUILTSOURCES otherwise it would have been left out from distributions as it wans't passed to any product_SOURCES nor EXTRA_DIST variables.

Notes, notebook, tabs

The notes plugin features a notebook since the port to Xfce 4.4 and in the last release I hide the tabs and gave a try to a new navigation bar. Seems you like the tabs so no worries it will be back in the next release.

Update: Revision 7717 has an option to show the tabs.

Xfce Clipman Plugin 1.0.0

This post is about the latest release of Xfce Clipman Plugin, a Clipboard Manager for the Xfce desktop. I turn it more technical than for end-users. I hope people interested into GTK+, GObjects or Xfce panel plugins will like to read it. The release is going to happen very soon now.

The first major change concerns the plugin being entirely rewritten by using GObjects and Xfconf, this means cleaner, better understandable, maintainable code, etc. There is the "main function" (for sack of clarity) and four objects. A collector which listens to clipboard changes and put them in the history, the history is also an object, a menu (on top of GtkMenu) that displays the history and allows to clear it, and finally another object which is part of a new feature for the clipboard manager.

Now having my objects it's just about instantiating them in the main function and binding them to Xfconf. If there is something missing in an object it is just about modifying a particular aspect of it.

The goal of using Xfconf is to have a less cluttered code for settings, and to make good use of property bindings against the objects. For instance, the object History has a maximum count of items, and being bind against Xfconf, it is possible to run an external command with xfconf-query to change that setting, without having to call a public setter function. Binding a property is a one function call.

Following this major change is the settings dialog. I have written it from scratch with Glade, a UI designer for GTK+, by which I can easily modify and beautify the dialog without having to fight with lines of code several hours a day. In fact it takes a few seconds to change a label and up to 5 minutes to design a goddamn dialog. Glade makes an increased use of memory however, but stop thinking of this when you know you have 1MB times 1000 installed on your system — I have currently 1GB on a netbook and 2GB on a quite-fanless Atom-based workstation but I use only around 300MB in general. If you still fear about having an application that uses only 2 but 5MB with Glade, well I can't help you! From what I have read, the built-in UI designer of GTK+, named GtkBuilder, needs less memory, but the Glade to GtkBuilder conversions are going to happen with Xfce 4.8.

Now about the new feature introduced into this major release. It is called "Actions" which is the fourth object by the way. An action is a match between a text selection and regexes to let you execute specific commands. For example the action "Image" can match text with image filenames and let you choose commands between "View with Ristretto" and "Edit with Gimp". I wrote something simple in the settings dialog to add new actions that is inspired from the Thunar User Custom Actions interface.

Finally, I made other changes that are more geeky than useful, like I made a bundle out of the plugin. The plugin is now installed under the binary directory instead of the common place holder for panel plugins but can still be added inside a panel with the "Add Item" menu action. As you might understand, it can be executed as well now, and if you do so it will run inside the notification area. An item is installed in the applications menu to be able to start it (under the category Utility), and as it is possible to run outside the panel, I added a autostart file.

That's it already. If you have questions, don't mind. If you wanna discuss the Actions/regex feature go ahead. More importantly, I hope you'll take a glimpse at the code.

If you are interested into panel plugins, have a look at the wiki. The panel plugins amongst the goodies are a good way to get to know code and start with something.

Update: ANN: xfce4-clipman-plugin version 1.0.0 released

Refresh the Xfce background

In Xfce 4.4 there was a little hack that worked to refresh the background. I managed to get the same result for Xfce 4.6 with the following "hack":

#!/bin/sh
if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ] ; then
        . ${HOME}/.dbus/session-bus/`ls -rt ${HOME}/.dbus/session-bus/ | tail -1`
        export DBUS_SESSION_BUS_ADDRESS
fi
PATH=/usr/local/bin:${PATH}
MONITOR=${1:-0}
PROPERTY="/backdrop/screen0/monitor${MONITOR}/image-path"
IMAGE_PATH=`xfconf-query -c xfce4-desktop -p ${PROPERTY}`
xfconf-query -c xfce4-desktop -p ${PROPERTY} -s ""
xfconf-query -c xfce4-desktop -p ${PROPERTY} -s "${IMAGE_PATH}"

Now when will this be useful? Barely never. Still enjoy it :-)

Update: script snipped updated to run within a cronjob.

Vala Notes Plugin

Or better, there is Vala in the Notes plugin. It's been a long time I thought about a hypertext view widget for the notes plugin, so it can highlight links and open them on click, and doing this in pure C/GObject is quite a PITA because there is a lot to take care about (more lines of code), and then you didn't start thinking about the whole functions of the object. Now this is retro with the presence of Vala. I played with Vala some time ago, doing some very rudimentary hello worlds, and I never had a chance to really write something in Vala, untill two days ago. I started to write a very dummy object on top of GtkTextView that implements the simple undo/redo feature I wrote inside notes.c and it was very fast and easy to backport from the C code to Vala, and this gave me a very good start with Vala (now that was one Vala too much, wasn't it? anyway...). Yesterday I added skel functions to support hyperlinks which I finished today. Finally I integrated the Vala object inside the notes plugin in a way that it compiles to C code when you are in MAINTAINER_MODE, which means for end-users they won't need Vala but only gcc.

Now for those interested into Vala, here is the file I played with: hypertext.vala. This source contains at the end of the HypertextView class, another class that contains a main function so it can be compiled to a binary. This proves how easy it is to test a class, and all you need to do is to run the following command: valac --pkg=gtk+-2.0 hypertextview.vala && ./hypertextview.
There are many samples available with the source of Vala and on Gnome Live. The tutorial covers important points, the FAQ too, but the documentation is a little less interesting if you already know GObject IMHO.
One important thing I learned about Vala was the difference between the out and ref arguments.

If you have a hard time at finding the right method definitions, look into /usr/share/vala/vapi/gtk+-2.0.vapi for instance for GTK+. There you can quickly find any function name you now from the C API, for instance if you want to have a look at gtk_text_view_get_iter_at_location search for get_iter_at_location. By scrolling up you will see that you are in the class Gtk.TextView. Vapis are very easy to read.

I am very interested into porting the objects of the Xfmpc project to Vala, and then start trying out the plugin sample (loading modules during runtime)... I hope my fellow will like that idea :-)

Now for the people interested to develop Vala classes with VIM I have some tips. First follow these instructions in order to get Vala syntax. Then I suggest you install the Tag List plugin, and to get it working with Vala you will need to add the following lines to your vimrc configuration:

" Work-around Tag List
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'

If you don't know about folding then you miss a lot of VIM culture, in fact you can fold/unfold brackets by going over a bracket and typing zf% in command mode. And that's all folk, thanks for reading til here.

./shoutcast-radio

Just like my older post about a "./jamendo-player", this time I am definitely more interested into good online radio stations. And SHOUTcast is the best that comes to my mind! It's been there for years, Winamp is the best music experience ever, and both have been promoting each other even though I don't know/remember what their relation are.

The good things about their widget is that it saves the recent radios and it also has a list of favorites but this one isn't working as-is with the code. It is possible to search for radios and to browse by genre. All of this stuff is saved under ~/.macromedia/Flash_Player/#SharedObjects/<random>/ct.yourminis.com/.

So of course I couldn't resist but embed their available Flash widget inside a window :-) Again the code is very short, it's just about loading — well not a URL this time — an HTML string cause the Flash application all alone doesn't work out, it needs parameters passed outside. I didn't include the callbacks to handle "_blank" links, which means it is not possible to open any links, but this is useless as the widget is fully functionnal.

You can download the source code here.

Here are some installation instructions:

1. Look into main.c
2. The first line of main.c is a comment with a command to compile
3. If you want a menu item in you desktop menu:
   1. Edit the Exec keys in shoutcast-radio.desktop
   2. Copy the desktop file to ${XDG_DATA_HOME:-~/.local/share}/applications
4. If you don't have a gnome-radio icon, copy gnome-radio.png to ~/.icons/
   

By the way, I'm linking on the Xfce blog. Why? Cause there might be Xfce users interested into a simple to compile radio application. At least I hope some of you will enjoy it, more than the jamendo thingy :)

Update: The favorites actually do work, it just that the favorite button isn't always clickable.