Inspirated

For a little while now I noticed that my Compiz skydome was disappearing whenever I logged in. I could bring it back by disabling and re-enabling the Cube plugin but from a cold-boot I was always greeted to an abysmal looking cube:

(Click on the thumbnail for larger version.)

A little bit of forensics revealed that the issue lied with the loading order of Compiz plugins. At the moment Compiz does not try to resolve any plugin dependencies at startup, so while the skydome relied on the PNG plugin the latter wasn’t pre-loaded — resulting in a blank background.

The solution was to change the following line in config:

[core]
s0_active_plugins = core;composite;opengl;copytex;decor;vpswitch;mousepoll;firepaint;gnomecompat;resize;compiztoolbox;wobbly;cube;screensaver;shift;scale;regex;imgpng;splash;place;move;obs;animation;rotate;expo;workarounds;freewins;ezoom;session;staticswitcher;

To:

[core]
s0_active_plugins = core;composite;opengl;copytex;decor;vpswitch;mousepoll;firepaint;gnomecompat;imgpng;resize;compiztoolbox;wobbly;cube;screensaver;shift;scale;regex;splash;place;move;obs;animation;rotate;expo;workarounds;freewins;ezoom;session;staticswitcher;

imgpng had to be loaded before cube, giving me back the pretty backdrop for all things 3D:

(Click on the thumbnail for larger version.)

Apple fans have Dashboard. KDE folks have Plasma. Gnome/Xfce people have, er.. tough choice.

Everyone likes desktop widgets. They’re pretty, and can prove to be really helpful with careful setup. Over the past few years, I have tried a few different widget frameworks and it’s kind of a strange phenomenon that all of them died the slow open-source death. adesklets, gDesklets and now Screenlets have bitten the dust. Screenlets, however, deserves special mention because of being the most recent among the deceased.

People behind Screenlets deserve credit for providing an easy-to-use framework for desktop widgets, which wasn’t the case with adesklets or gDesklets. Nevertheless, the compliment is in a way reserved for the basic framework and not the screenlets themselves. While it was fun and easy to write new widgets in Python, the existing ones were broken more often than not. There must be 100+ screenlets available online right now; pick any recent vanilla distribution and a considerably many will fail to work properly on it. Perhaps this is one of the reasons why the package never made it into Fedora repositories. The base product had significant potential, but the end-results built upon it were — in the greater picture — largely a disappointment. Before the situation improved however, Screenlets passed away quietly. Without even an obituary on Wikipedia or the project page itself. People like me who were waiting for a stable release kept finding out through Launchpad comments that development has split and moved to a new project called Universal Applets.

UA is still in early development stages, and does not offer even all the features present in Screenlets’ last version (such as widget zoom). But at least among all the remaining Gtk+ widget frameworks, it remains the only one with active development going on. While I wish its developers good luck for what appears to be a more promising framework than any of the ones mentioned above, I can only hope that it doesn’t disappear into obscurity like its ancestors — resulting in a Yet-Another-Widget-Framework. Meanwhile, I’m sticking with Screenlets’ last release since it works reasonable well once you’ve sorted individual widgets’ kinks out.

Sometimes, migrating to Qt doesn’t sound all that bad of an idea.

In past, I had always struggled to find the “correct” way of launching Compiz Fusion while starting Xfce. For a while, I had resorted to the easiest — and not perhaps the prettiest — way of launching Fusion Icon with the desktop autostart files. The problem with this method lied in the fact that Xfwm was launched before Fusion, and the most glaring workaround was to write my own xinitrc files for X startup, which was just uglier anyway.

Xfce’s own documentation is as bare as my memory while running it, so the right way was not actually obvious until I was fiddling around my configuration directory a few days ago. There, I found an interesting file named xfce4-session.xml. To truly exploit this lovely thing, I first copied it into my home configuration directory:

[krkhan@orthanc ~]$ cp /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml

And then edited the file with a text-editor, making it look something like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<?xml version="1.0" encoding="UTF-8"?>
<channel name="xfce4-session" version="1.0">
  <property name="general" type="empty">
    <property name="FailsafeSessionName" type="string" value="Failsafe"/>
    <property name="SessionName" type="string" value="Default"/>
    <property name="SaveOnExit" type="bool" value="false"/>
  </property>
  <property name="sessions" type="empty">
    <property name="Failsafe" type="empty">
      <property name="IsFailsafe" type="bool" value="true"/>
      <property name="Count" type="int" value="5"/>
      <property name="Client0_Command" type="array">
        <value type="string" value="fusion-icon"/>
        <value type="string" value="--force-compiz"/>
      </property>
      <property name="Client0_PerScreen" type="bool" value="false"/>
      <property name="Client1_Command" type="array">
        <value type="string" value="xfce4-panel"/>
      </property>
      <property name="Client1_PerScreen" type="bool" value="false"/>
      <property name="Client2_Command" type="array">
        <value type="string" value="Thunar"/>
        <value type="string" value="--daemon"/>
      </property>
      <property name="Client2_PerScreen" type="bool" value="false"/>
      <property name="Client3_Command" type="array">
        <value type="string" value="xfdesktop"/>
      </property>
      <property name="Client3_PerScreen" type="bool" value="false"/>
      <property name="Client4_Command" type="array">
        <value type="string" value="xfce4-settings-helper"/>
      </property>
      <property name="Client4_PerScreen" type="bool" value="false"/>
    </property>
  </property>
  <property name="splash" type="empty">
    <property name="Engine" type="string" value=""/>
  </property>
</channel>

Lines 13-15 initially referred to Xfwm’s commands, but replacing them with the Fusion Icon ones worked like a charm. This way, Fusion is always guaranteed a launch, which actually wasn’t the case with other workarounds.

Recent X.org drivers for Intel chipsets have introduced a new acceleration method called UXA which is supposed to provide “simpler, faster” code. However, for whatever reason, this bleeding-edge feature actually results in a loss of performance and reliability for particular chipsets (e.g. 915 family) on most distributions (Fedora and Ubuntu to name the foremost). In order to work around these issues, two solutions can be used:

1. Enable Tiling in xorg.conf.

   Section "Device" Identifier "Videocard0" Driver "intel" Option "Tiling" "False" EndSection

   Section "Device" Identifier "Videocard0" Driver "intel" Option "Tiling" "False" EndSection

   This fix does help the low framerate issue encountered on most distros, but it introduces screen tearing on some installations and worse, can happen in occasional X crashes as well.

2. Use “greedy” MigrationHeuristic with EXA instead:

   Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" Option "NoDDC" EndSection

   Section "Device" Identifier "Videocard0" Driver "intel" Option "AccelMethod" "EXA" Option "MigrationHeuristic" "greedy" Option "NoDDC" EndSection

   While this completely bypasses the UXA acceleration, it seems to work well for most users.

For the time being, I’m sticking with the second workaround since I have no issues with using the older acceleration architecture until the new one achieves some decent stability.

Conky is a small utility for X systems which displays various system statistics and graphs on your desktop. The tiny piece of software is highly configurable, exceptionally light-weight and well … Zooey Dischanel-ly sexy — that’s officially an adverb now, your disagreement doesn’t matter. In layman’s terminology, it’s the “green” stuff on far left:

(Click on the thumbnail for larger version.)

Be the screenshot as it may, here‘s how I pimped the stats. To use the same settings for your setup, replace your configuration file at ~/.conkyrc with the one at provided link and restart Conky. You’ll get the following:

• Processors usage bars and graphs for a multiple core CPU.
• Memory usage bars and graphs.
• Disk usage bars and graphs.
• Network traffic graphs. You may have to change the interface in configuration file from wlan0 to the one your system has.
• CPU temperatures. You need lm-sensors to make these work.
• Track currently playing in Audacious Media Player.

Just because rides aren’t pimp-able with a text file.

“We live only to discover beauty. All else is a form of waiting.” — Khalil Gibran