Alexander Kojevnikov | Blog

I've just released a new version of xmonad-log-applet. Thanks to Ari Croock it now works with the MATE desktop environment, just include --with-panel=mate when configuring the applet.

Because GitHub recently disabled new downloads, the tarballs are now hosted on Google Code.

I also added a new tag for the applet in case you want to follow just x-l-a related posts.

The GNOME and Mono Festival of Love was a blast! I finally met Bertrand and Aaron -- my fellow Banshee co-maintainers; as well as a lot of GNOME and Mono people. I also met Udesh, the SoC student I'm mentoring this year, who is working on voice control in Banshee.

I reviewed and committed a bunch of (mostly long overdue) patches in Banshee and taglib-sharp, and released a new version of the latter. We also discussed with Udesh his project and went through some technicalities.

I want to thank David for organising the event, GNOME Foundation for covering my plane tickets and our sponsors for making it happen:

Thanks to the travel sponsorship of the GNOME Foundation, this week I'm going to Boston to attend the hackfest. I will be in Boston from Thursday evening till Sunday afternoon.

Looking forward to finally meeting fellow Banshee developers!

xmonad-log-applet is a handy panel applet/plugin for GNOME (and now Xfce) users who use Xmonad as an alternative window manager. The applet will show the visible workspace(s), active window's title or anything you send its way from your xmonad.hs.

I recently took over xmonad-log-applet maintainership from Adam Wick, and today I'm happy to announce the release of version 2.0.0.

Changes since the previous release:

• Migrated the GNOME 2 applet from deprecated libbonobo API to the new D-Bus based API.
• GNOME 3 panel support (in fallback mode).
• Xfce 4 panel support.
• Revamped the build system.
• Dropped GConf dependency which was used to specify the applet width; instead fill all available space (like the window list applet) and ellipsise when necessary.
• Simplified background transparency handling.
• Fixed install locations.
• Updated sample xmonad.hs.

To install get and unpack the tarball or clone the repo, then run:

% ./configure --with-panel=gnome2
% make
% sudo make install

Substitute gnome2 with gnome3 or xfce4 if that's what you use. If you cloned the git repo, use ./autogen.sh instead of ./configure. After restarting the panel you should be able to add the applet.

Use the provided sample xmonad.hs file to bind it to Xmonad. It depends on the DBus package, which currently doesn't compile with GHC 7.x, but it's easy to work around:

% cabal update
% cabal unpack DBus
% cd DBus-0.4
% $EDITOR DBus/Internal.hsc

Replace import Control.Exception with import Control.OldException, then:

% cabal configure
% cabal build
% cabal install

After this, your xmonad.hs should compile.

EDIT: With GHC 7.4, you also need to edit DBus/Message.hsc and prepend Foreign. to unsafePerformIO.

Happy Xmonading!

xmonad is an elegantly minimalist and lightning fast window manager for X written in Haskell. I wanted to play with it for a long time: I'm using two 24" monitors and so have to spend a fair bit of time re-sizing windows and moving them around. A tiling window manager like xmonad takes care of this; in addition you can control all aspects of window placement with the keyboard alone.

The good news is: xmonad plays really well with GNOME. You can keep your GNOME panels, themes, desktop backgrounds, etc – xmonad just replaces Metacity leaving everything else intact.

The bad news is: I should have tried it earlier.

A few notes about xmonad set up and usage:

• Recommended way to set up xmonad with GNOME is to export WINDOW_MANAGER=xmonad before starting gnome-session, but it didn't work for me. I tried every suggested place: ~/.gnomerc, ~/.xsession, ~/.profile, ~/.xinitrc; but none of them worked – GNOME always started with Metacity.

  What worked though is this:

• Create a file in /usr/share/applications called xmonad.desktop:

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Xmonad
Exec=/usr/bin/xmonad
NoDisplay=true
X-GNOME-WMName=Xmonad
X-GNOME-Bugzilla-Bugzilla=XMonad
X-GNOME-Bugzilla-Product=xmonad
X-GNOME-Bugzilla-Component=general
X-GNOME-Autostart-Phase=WindowManager
X-GNOME-Provides=windowmanager
X-GNOME-Autostart-Notify=true

• Change this GConf key from 'metacity' to 'xmonad':

/desktop/gnome/session/required_components/windowmanager

• On startup, xmonad doesn't set the usual left-arrow cursor but inherits an ugly X cursor which looks like it was created in the eighties. To change it, add this line to your ~/.xinitrc file just before you start gnome-session:

xsetroot -cursor_name left_ptr

• You need to create a config file in ~/.xmonad called xmonad.hs and add this:

import XMonadimport XMonad.Config.Gnome main = xmonad gnomeConfig

• That's right, the config file is a Haskell program that starts xmonad, which means it's extremely customisable.

  All keyboard short-cuts in xmonad are in the form Mod-X or Mod-Shift-X, where Mod is by default the Alt key. Line 7 tells xmonad to use the Win key – Alt is heavily used by GNOME applications:

import XMonad
import XMonad.Config.Gnome

main = do
  xmonad $ gnomeConfig
    { terminal    = "gnome-terminal"
    , modMask     = mod4Mask
    , focusFollowsMouse = False
    , borderWidth = 2
    }

• When touch-typing, some shortcuts are painful to use, Win-Shift-6 probably being the worst. What I wanted is to replace the Mod part with another shortcut, a bit in the Emacs fashion, so that instead of Win-Shift-6 I would have for example a sequence of Ctrl-m and Shift-6.

  mauke on #xmonad was extremely helpful, he came up with this code which worked as advertised:

import XMonad
import XMonad.Config.Gnome
import XMonad.Actions.Submap

import Control.Arrow
import Data.Bits
import qualified Data.Map as M

main :: IO ()
main = do
    xmonad $ gnomeConfig
         { terminal = "gnome-terminal"
         , focusFollowsMouse = False
         , borderWidth = 2
         , keys = addPrefix (controlMask, xK_m) (keys gnomeConfig)
         }

addPrefix p ms conf =
    M.singleton p . submap $ M.mapKeys (first chopMod) (ms conf)
    where
    mod = modMask conf
    chopMod = (.&. complement mod)

• To re-load xmonad after you changed the config file just press Mod-q. It takes just a second to re-compile and leaves all open windows intact.

After using xmonad for 2 days I must say I'm a convert. The keyboard short-cuts feel very natural, it's not difficult to see the influence of vi. Moving a window to another screen or to another workspace (did I mention workspaces are per screen, which is a really neat feature), switching between workspaces, switching windows, changing layouts, etc... is just a short-cut away.

And as a bonus point, I now have a good reason to become more familiar with Haskell – it's a very nice language.

Banshee 1.6 will include an updated Play Queue extension. The changes are already in git master, here are a few teaser screen-shots:

Played tracks are not removed from the queue but are shown as greyed out. You can play them again if you want, drag and drop to the back of the queue, delete, etc.

The number of played tracks to show can be changed from the preferences dialogue.

You can also ask Banshee to automatically update the queue using any shuffle mode (including the new by rating and by score modes). The number of upcoming tracks can also be changed in the preferences.

The tracks are taken from the entire library or from any play list.

If you don't like what has been added, you can refresh the upcoming tracks. Or you can add more of them (thanks Sandy!)

Tracks added manually are treated differently from those that had been added automatically. When adding, they are inserted to the front of the queue but after other manually-added tracks.

Also, they are preserved when you refresh the queue.

That's about it. If you like what you saw you can try the git master version. Otherwise just wait until 1.6 is out, it shouldn't take too long.

Next version of Banshee will introduce two new shuffle modes: by rating and by score. In this post I will explain how they work since the modes can be a bit confusing.

In the random shuffle mode (aka shuffle by song), every track has an equal probability to be selected. For example if our library contains 1,000 tracks, each of them will be chosen with probability

P_t = 1 ÷ 1,000 = 0.001

But what if we want some tracks to be played more often than others? Say we have 100 favourite tracks and want to play each of them three times as often as any other track? In probability terms this can be written as

P_s = 3 × P_t

where s are our favourite tracks and t – the other 900 tracks in the library. Because the sum of all probabilities must be equal to one, we have

100 × 3 × P_t + 900 × P_t = 1 → P_t = ¹/_1,200

To chose the next track, we can pretend that our library contains 1,200 songs and pick one at random. If the track number is ≤ 100 × 3, we randomly select one of the 100 favourite songs, otherwise we take one of the 900 remaining songs.

If the library is partitioned into n slots, each containing C_i tracks, we will have

∑_i=1,n C_i ⋅ w_i ⋅ P₁ = 1

where P₁ is the probability of selecting a track from the first partition, and w_i tells how frequently tracks from the i-th partition should be selected compared to the first one. That is P_i = w_i ⋅ P₁

Numbers w_i are called weights and by changing them we control how often the songs from different slots are played. For example, we could pick a number (lets call it β) and require that songs from the second partition are played β times as often as the songs from the first one, songs from the third β times as often as the songs from the second, and so on. That is, w_i = β^i-1

For ratings, we have 5 partitions – one for each rating. We could also put all unrated songs into the 3-rd partition (to treat them as songs with 3 stars) so that our entire library is partitioned. Now a good question is what to use for β?

If we take β=1, all songs will have an equal probability to be selected. Note that it's exactly the same as the shuffle by song mode. If we take β=2, songs rated 5 will be played twice as often as songs rated 4, and so on.

In Banshee we use β = φ ≈ 1.61803, also known as the golden ratio. This number has an interesting property:

φⁿ = φ^n-1 + φ^n-2

In terms of ratings, it means that songs with 5 stars will be played as often as songs with 4 and 3 stars combined, and so on.

In the shuffle by score mode, the songs are partitioned into 20 slots, first slot for the songs scoring 1…5, second – for 6…10, and the last – for scores 96…100. We also put songs with no score into the 10th slot (46…50).

We cannot use φ for β because this time we have much more partitions – the songs with low scores would be hardly ever played. To keep scores behaving similar to ratings we need to scale the weights:

β = φ^¼, w_i = φ^(i-1)/4

Hope that wasn't too tangled and I promise next post won't include a single formula :)

I'm happy to report that the subject is mostly fixed.

Window List: bgo#86382 has a working patch, it's not perfect (read comments 140, 141 and 145) but fixes the problem.

Notification Area: bgo#531371 also has a patch which works really well.

Quick Launch: My fix is included in version 2.12.6 of the applet.

Main Menu: The ugly arrow (bgo#562247 and bgo#564903) can be removed by setting "has-arrow" to FALSE in gnome-panel/panel-menu-button.c

Keyboard Indicator: bgo#591515 is not yet fixed. A quick and dirty hack is to comment out the entire switch statement in GSwitchitAppletUpdateAngle() function from gswitchit/gswitchit-applet.c

I'm using a GNOME desktop with all these fixes daily and I'm quite happy with it. You can get my customizepkg files for Arch Linux from GitHub; read how to use them in the previous post.

UPDATE 2009-09-06: Read the follow-up post

I've been playing with various desktop GNU/Linux distributions last couple of months. I'm not exactly a newbie to Linux, I have been administering a VPS box for a hobby project for several years now, but I never managed to play with it on a desktop.

So I did. And I must say I'm very impressed. Last time I checked (FreeBSD 4 back in 2000), FLOSS desktop was mostly a geek toy, these days it is ready for the average user.

I will spare the overview of the distros that I tried, as well as my take on the KDE vs. GNOME flame war for another post, here I want to talk about one particular annoyance that I really want to see fixed.

You see, these days it's hard not to have a wide-screen monitor sitting on your desktop. They are great for watching films and playing games but this comes at a cost -- you end up with fewer vertical pixels.

Vertical space is much more important for most other tasks I do on the computer, be it browsing the web, coding or writing blog posts. And the only way to maximise it is to move the everlasting task bar sitting on the bottom of most operating systems to the left or right of the screen.

This is how it looks like in Vista and KDE. I know it takes some getting used to, but it's worth a few days of slight disorientation. And I'm not the only one who thinks so.

The vertical layout works great in XP, Vista and KDE, but not in GNOME. I want to list here all open issues along with the links to the GNOME bug database. I guess we have all these issues because not many GNOME developers are using the vertical layout, or even aware of the benefits it can give them. I hope this post will help it, even if only a little bit.

Window List: The list of open windows is arguably the most important piece of information sitting on the panel. And the most terribly behaving in vertical layout.

First of all, the height of the window list applet is fixed, meaning the list doesn't occupy all available vertical space.

Second, the height of the buttons that represent the open windows, stretches to fill the entire applet. The buttons should have a fixed height that depends on the font used in the buttons.

Third, after you open a few windows, the list splits to two columns and becomes irresponsible to mouse clicks. This is the most annoying bug of the three.

These issues are documented in bug 86382 that was open back in 2002! The bug has a patch, but it looks like it's not perfect either.

Notificatioin Area: In vertical layout the notification area wastes a lot of space by placing one icon in a row. It also uses different sizes for different icons, some are really huge, e.g. 128x128. It should instead use a flow layout for icons and use the same size for all of them. This is described in bug 531371.

Quick Launch: The quick-lounge applet had a bug that made it nearly impossible to use on a vertical panel (see bug 531358). It's fixed now in the trunk, hopefully it will be integrated into the next GNOME release.

There are other related annoyances (see bug 428943 and Ubuntu idea #1906) but I can live with them if the above issues are resolved.