Inspirated

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.

If there has been a closed-source software which I have enjoyed using at my university, it’s Emu8086. The shareware, as the name suggests, emulates the 8086 processor down to the minutest detail. Since 8086/8088 processors form a significant part of my Microprocessor Interfacing & Programming course, I have grown rather fond of the software’s workings.

Recently, I needed to generate hardware interrupts on the emulator. Not only that, but I wanted to use my own service routines for the interrupts so that I could try to understand what happens behind-the-scenes in such scenarios. Reading through the Emu8086 documentation, I figured out that two files are responsible for accomplishing the required tasks:

1. INT_VECT: A 1024-byte interrupt vector containing 256 entries, with each entry being a 4-byte offset:segment pair.
2. emu8086.hw: A 256-byte file with each byte representing a corresponding interrupt. A non-zero byte signifies that particular interrupt being active. The byte is set to zero again after the interrupt is serviced.

As manually editing these files became cumbersome, I had to code two PyGTK apps for editing these files in a pretty interface:

(Click on the thumbnail for larger version.)

The intvecteditor.py file lets the user load/edit/save an 8086 interrupt vector. Similarly, the hwintgen.py allows the user to load an emu8086.hw and then generate/monitor interrupts in it. The utilities require PyGTK to run, but I find it infinitely easier now to analyze interrupt behavior of the emulator. This also lead to an interesting observation, as the emulator checked for interrupts at the beginning of an instruction instead of at its end — something which didn’t confirm with the actual 8086 working model.

x86 is fun. After all,

“Do you program in assembly?”
“NOP”

Update: New version

While visiting profile of a friend, I noticed that he and I had about 70 mutual friends. Immediately it gave me the idea to plot the common friend connections and see what interesting patterns emerge in the larger picture. Something like this:

In the sample above, the names in circles (“nodes”) happen to be in my friend list. The connecting lines represent their own friendship status. For example, Saad Jasra and Hassan Ahmad are friends among themselves apart from being my friends on their own. Similarly, Ali Zeeshan Ijaz is a friend of both Saad Jasra and Abdullah Afaq Ali.

Luckily, Facebook API had Python bindings available which considerably simplified my task. Those, coupled with pydot, resulted in a dot file with all the required connections. Graphviz did the remaining work:

(Click on the thumbnail for larger version.)
(Warning: The larger version is a 7329x5953 PNG image with a humongous file size of 13 MB. If your hardware specs are squeamish, don’t blame me if it brings your machine on its knees — this is not a DoS attack.)

Now came the intriguing part. The resulting graph was visibly split in two large portions. This resulted from the fact that I had spent a major portion of my life (15 years to be exact) in Saudi Arabia before moving to Pakistan. More interestingly, an old friend of mine from Saudi Arabia — Atif Sheikh — was also enrolled at my university in Pakistan. When I zoomed into the graph, I spotted him at the nexus of two networks. Similarly, the names in the middle of a network were the most connected people in that network. That is, the names congested in the middle of Pakistan network were friends from university and the names at the edges of that network were friends outside the university who didn’t share my academic connections.

I haven’t polished the code for a stable release yet as I doubt that other people would be interested in having gigantic plots of their social lives. Nevertheless, I’ll try to package it in form of a proper Facebook application in near future. After all, as I quoted in a previous post of mine:

“Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital.”

I had never really laid my hands on LaTeX until I required it in one of the helper applications for my graduation project. Unfortunately, the requirement wasn’t as simple as producing some documents as I had to embed mathematical expressions on the fly in my PyGTK apps. Googling around for the solution, I found GtkMathView which accomplished something similar to this albeit using MathML. However, my luck ran out on me again as the widget lacked Python bindings. The other solution was to generate transparent PNGs on the fly and include them as GtkImages. This worked rather well, as the final code allowed easy modifications to the generated expressions.

Requirements for the code were:

• LaTeX
• dvipng
• latexmath2png

Final results:

And the simple code behind it:

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
40

#!/usr/bin/env python
"""An example demonstrating usage of latexmath2png module for embedding math
equations in PyGTK
 
Author: Kamran Riaz Khan <krkhan@inspirated.com>
"""
 
import gtk
import os
import latexmath2png
 
pre = 'gtktex_'
eqs = [
	r'$\alpha_i > \beta_i$',
	r'$\sum_{i=0}^\infty x_i$',
	r'$\left(\frac{5 - \frac{1}{x}}{4}\right)$',
	r'$s(t) = \mathcal{A}\sin(2 \omega t)$',
	r'$\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}$'
	]
latexmath2png.math2png(eqs, os.getcwd(), prefix = pre)
 
def window_destroy(widget):
	for i in range(0, len(eqs)):
		os.unlink(os.path.join(os.getcwd(), '%s%d.png' % (pre, i + 1)))
	gtk.main_quit()
 
window = gtk.Window()
window.set_border_width(10)
window.set_title('LaTeX Equations in GTK')
window.connect('destroy', window_destroy)
vbox = gtk.VBox(spacing = 10)
window.add(vbox)
 
images = [None] * len(eqs)
for i in range(len(eqs)):
	images[i] = gtk.image_new_from_file('%s%d.png' % (pre, i + 1))
	vbox.pack_start(images[i])
 
window.show_all()
gtk.main()

Recently, I needed to create some visualizations in a drawing area for one of my PyGTK apps. The PyGTK tutorial had an excellent writeup complete with a working example for immediate help. Unfortunately, my requirements were of a “grid” view on which other objects would be drawn. Naturally, I hoped for some variable on the GtkDrawingArea which I would set to true and have the grid lines drawn automatically. But since I couldn’t find any such magic setting in the API, I had to draw the lines manually.

Consequently, I could use either of the following approaches:

• Loop horizontally and vertically while draw_line()ing.
• Draw a 10×10 box as a tile and repeat it over the background.

The first approach would’ve worked faster but involved writing more code. The second was uglier — especially for larger images — but resulted in me having to add only a few lines to the example:

72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

        xpm_data = ["10 10 2 1",
            " 	c #EEEEEE",
            ".	c #FFFFFF",
            "          ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            "          "]
        tile_pixmap, tile_mask = gtk.gdk.pixmap_create_from_xpm_d(
            area.window, None, xpm_data)
        tile_gc = area.window.new_gc(fill = gtk.gdk.TILED,
            tile = tile_pixmap)
        width = int(self.hruler.get_range()[3])
        height = int(self.vruler.get_range()[3])
        area.window.draw_rectangle(tile_gc, True, 0, 0, width, height)

Turning this:

Into this:

Note that the 10×10 tiles’ borders match prettily with the markers on top and left rulers. There will definitely be some more efficient method for achieving this but for the time being tiling serves my needs perfectly.

Rarely do I feel the urge to jump on the buzzword bandwagon. This time, however, the product deserves the hype. Before you hear me any further, jump straightaway to the Nokia 900 website and stagger yourself into oblivion. Cliff notes:

• First Linux-based cellphone from Nokia — world’s largest manufacturer of mobile phones. The previous Linux tablets from the Finnish giants (e.g., N810) were nice but lacked the basic phone functionality.
• A plethora of insane mouth-watering features that are just too many to list here in their entirety.
• S**.

If you still aren’t convinced, let me be lazy and shamelessly copy some items from the linked page:

• ARM Cortex – A8 superscalar microprocessor core running at 600 MHz
• Up to 1 GB of application memory (256 MB RAM, 768 MB virtual memory)
• 3D graphics accelerator with OpenGL ES 2.0 support
• 32 GB internal storage
• 3.5G and WLAN connectivity
• Quadband GSM with GPRS and EDGE
• 5-megapixel digital camera
• Carl Zeiss optical lens
• Touch-sensitive screen
• Assisted-GPS receiver

Essentially, that’s iPhone+N810+N96+Neo FreeRunner for you. An year ago, I did have a feeling that Nokia was planning big things with Linux when it acquired Trolltech but I had absolutely no idea that the definition of “big” would be this exotic.

Can’t. Wait.

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.

Ladies and gentlemen, let’s bring our hands together for a clamorous round of applause. The greatest browser plugin since the invention of, well… browsers, has been unveiled. Welcome to Quake Live.

An year ago, anyone proposing the idea of running Quake III in a browser would have been sent to the local psych ward. Heck, even a week ago I would’ve been skeptical about practicality of any such development. But sometimes, it just feels wonderful to be proven wrong. This is one of those times and while I shoot railguns aimlessly in the other Firefox tab, I just can’t help staring at the screen in awe. In fact, I can even — for the time being — totally overlook any security concerns related to the plugin. If you own a decent browser, QL’s worth at least a try. I’m not a FPS fan either but this was just too good to be overlooked because of gaming preferences.

Going through the Planet Fedora feed, I spotted this excellent write-up which tries to explain Fedora-related patent questions such as “why the $*#@ won’t Red Hat give us MP3 playback support“. I would be straight-down lying if I said that the article offered nothing new to me. In fact, some answers, such as this one … :

Patent licenses are usually granted via payment of royalty based on the number of users. Since Fedora is free and open source software, the effective number of users is essentially unrestricted. Patent holders are generally unwilling to give a blanket patent license for unlimited use, and the royalty payments for these licenses would be too high to purchase them outright. Proprietary operating systems like Microsoft Windows include the cost of the patent license as part of the product being sold to the end users. Fedora is not sold commercially, so there is no way to recoup these substantial expenses. Even assuming funds are available to do so, licenses such as the GPL require a written patent grant (in regions where software patents are enforced) compatible with royalty free distribution and modification. Since meeting this requirement effectively nullifies the effect of a patent, patent holders are also generally unwilling to do this.

… clarified in my mind a few long-held confusions about Fedora’s reluctance regarding patent infringement. For the general user, RPM Fusion works around all that crap; but a read of the linked FAQ is recommended nevertheless for having an idea about the issues inherently involved with seemingly simple tasks such as playing DVDs.