You don’t know how much you need something until you lose it…

A few weeks ago, I revived my six year old acer aspire, and set it as my default computer at home. But, for a year, my only machine had being a nice thinkpad that my employer, kindly offered me. One of the most useful features on my thinkpad is that next to the up arrow,  there are two buttons conveniently configured to go back and forward in the browser.

I don’t know why, but the folks in acer thought that it would be most convenient to have an euro and dollar sign next to the up arrow, which I don’t really use.

So, every time I wanted to go back in chrome, I was disapointed for such a bad choice on my laptop. Being a linux guy, instead of been frustrated, I decided to solve this issue. Here is what I did:

As the arch linux wiki explains [*], there are two concepts to learn first:

  1. The scancode is the most basic way of identifying a key in linux. This is an hexadecimal code the kernel assigns to each key it recognizes.
  2. The keycode is analogous to the scancode, but on a higher level. To every scancode there should be a keycode in order for the key to be useful. 

Finally, the X server translates those keycodes into symbols that it understand. Some of those symbols are usual characters to be print as text. But there are a few symbols which are special. In my case, the symbols that make the browser go back and forth are named XF86Back and XF86Forward (no surprises here, uh?)

Therefore to get the thinkpad behavior in my aspire what I needed to do was:
  1. Figure out the scancode of the buttons next to the up arrow.
  2. Find out what is the keycode that should assign to XF86(Back/Forward).

For the first task, I just have to open the file located at /usr/lib/udev/keymaps/acer and it contained the info. (It said that in my laptop those special buttons euro, and dollar where bound to the scancodes 0xB3 and 0xB4). I suppose for other machines there should be a simmilar file if udev is installed.

For the second task, I just googled ;-), somewhere I found that XF86Back should have 166 as keycode, and XF86Forward should be 167. I don’t know if this is a standard, but in my case it worked!
Finally, everything was put together with the next command, executed as root:
#setkeycodes 0xB3 158 0xB4 159

If you are good on math, you should have noticed that 166 = 158 + 8, 167 = 159 + 8. (You certainly did, don’t you? ;-). I learned that the reason for this is historical: What the kernel calls Keycode is not exactly the same the X server uses, but there is an offset of eight units between the kernel’s and the X server’s keycodes.

Voila!. My euro button know makes chrome go back and the dollar button makes it go forward, nothing I had missed more than that =D.
Note that in order to make the changes permanent, if you are on arch, you need to define a systemctl service just as the wiki says.

The good, the bad and the ugly: Lessons from DEs

I have been a happy linux user for many years, and as most experienced users know, it is almost imposible to have a linux box without having to write some scripts from time to time. To me, it was quite natural to start coding in a day to day basis. My first programs were really basic. Mostly bash scripts, and tons of python code. But, as my programming skills were growing up, I started learning to build compiled programs: C, C++, Java, Vala… you name it, and it’s very probable that I have tried it.

Going back a few weeks or so, I recovered my old first laptop, acer aspire 1660. And being now an experienced linux user, running on arch linux, I could not resist to attempt install only the most basic desktop environment which I could.
Installing arch was sweet, my boxed had two partitions, the first with  and old Ubuntu lts, from which I ran the arch build scripts. In a half hour, I got a working arch linux on the other partition. Being a geeky programmer, I decided that I don’t really need to have installed a lot of useless software if I can avoid it, which means I just wanted a window manager with nice candy like gnome-shell or kde, but without all the bloat that those heavy weight desktop environment use to have (the one size fits all philosophy, as I call it). In chronological order, this is what I have found, and what has kept me from sleeping at night.

The Bad

I knew I wanted candy, and by my previous experience, I knew that gnome-shell wasn’t what I was looking for, as I’m not very fond of the way gnome-shell manages the x-clients (windows),  I scouted which other DE  (Desktop Environment) would be more appropiated. I decided to fork cinnamon because its user interface follows the old desktop paradigm. Once forked, it was relatively easy to strip all the packages that I decided were useless for me. But being an arch linux guy, my last system update advanced gtk to gtk3.8, which were bad news, as I did not know that the gnome developers decided to change libdbus to GDBus, without worrying much of the people using their code (for instance the linuxmint project, authors of cinnamon!), and that immediately broke my DE!. After some research, I found how to solve the issue, but I am very unsatisfied with my solution, because I had to patch a previous version of cinnamon, not the bleeding edge last version!, and I wonder what could happen next time Gnome staff decided to change things on their project without worrying much about the others, and without a backwards compatible solution (because, admittedly, it would have costed nothing to keep libdbus along GDBus for a while, as cinnamon or any other project solve its compatibility issues). Therefore, in this post I dare to compare Cinnamon with the bad, but not because I think of it as a bad project, in fact, I like cinnamon, but because I think that being dependent on gnome-shell’s base is a bad decision (just my opinion as a user skilled in programming).

The Ugly

When my system crashed, I decided to try gnome-shell again. I will be breve because as I mentioned, I don’t like gnome’s paradigm: Under gnome, I spend more time thinking on how to move between activities, than focusing on my work, therefore as user, I knew that gnome-shell would be a very short stop, while Cinnamon solved the compatibility issues with GDBus. Moreover, as I stripped all the unneeded dependencies on the shell, I could not avoid to think on why on the name of the heavens and earth, the developers decided to hardcode the dependencies of the shell all along their code, I mean, I don’t really need an on screen keyboard (caribou) neither I do need a Network Manager applet, because I use netctl, or accesibility plugin, not to mention an account service, being the only one user of my old laptop. But in the shell it’s all or nothing, something that doesn’t happen in Cinnamon, where most dependencies where easily avoidable in the code (which means I almost had not to patch the C code, only the relevant javascript, in contrast to my experience with gnome). Therefore, I think of gnome-shell as the ugly. Yes, the ugly to hack!, which made to feel very uncomfortable with it, and which brings me to my last attempt to hack on my DE.

The Good

Elementary Os is a brand new desktop environment, with a modular, visually appealing design. Its window manager is a descendant of ol’ good mutter, this time written in vala, instead of all that javascript code in gnome-shell and cinnamon. On the developer side, which  I was more focused on my quest, I have to say that being modular make it very sweet. Once you get the basic library dependencies (elementary os is based on ubuntu, and have some minor dependencies on unity), everything just compiles! =D . Basically, what I needed for elementary to work was as follows:

  • Bamf: This is a small library which maps applications running to its correspondent desktop files. 
  • Indicators: These are the small icons which appear on the top bar of ubuntu’s unity. Developers say that indicators exist because the system tray specification is messy. I’m not expert in this area, so I just trusted what they say and compiled/installed this to get my desktop environment working 😉
  • Contractor is a library easing interprocess operation and the modular design of pantheon.
  • Plank is the project’s dock. As I understand, this is a fork of docky, and only have the most basic functionality of the later.
  • pantheon-wallpaper: Its only job is to paint the wallpaper.
  • Gala: This is pantheon’s window manager, derived from mutter. It works smooth and gives nice eye candy without compromising windows resources.

And that’s it, besides the basic libraries, everything is optional in pantheon, so I have other applications from the project, but they are not needed to have a basic environment:

  • Slingshot: This is an application launcher, no more, no less.
  • Switchboard: This is the equivalent to Ubuntu’s topbar, but I could not get the indicators that should go in the bar working, so I don’t really use it.
  • Cerbere: Small application whose only job is restart the main components (window manager, dock, launcher, etc) each time they died. I installed this reasoning that pantheon is beta and designed from Ubuntu, so, being an arch guy, it could happen that its components crashed a lot. However, that did not happen, and I could prescind from it without any fuss.
  • Scratch is a text editor with good support for vala.
  • Noise is a media player. I used it for two days, but lost interest on it, solely because I listen to music from youtube most of the time.
  • pantheon-files is a file manager, which reminds me dolphin in KDE (in fact, in some older blogs, I have found that people refers to it as marlin, so, this is another fishy file manager). It’s simple and just works, without many dependencies, so I use it in a regular basis.
  • pantheon-terminal: This one is my de facto terminal emulator. It’s interface is simple. Supports some candy (transparent background), and, as the other components, just works! =)

On the developer side, I find pantheon’s code clean and easy to understand. These guys decided to use cmake as building tool, and I really like it. My previous experience with gnome-shell and cinnamon (both use autotools for the task)  showed me the relevance of separating the source code from the building process, and cmake allowed to resolve the few dependencies that had to strip fairly easy.

In conclusion, my favorite desktop environment to this day is pantheon. It offers a good mix of eyecandy, performance and simplicity, and as a developer, its  clean, modular code, makes it easy to hack and port to other distributions from its original  Ubuntu. Certainly, it’s still beta, and there are other most heavily tested desktop environment, but I think this one is worth to try, and if you are a developer who is interested in tuning its DE, this is an easy one to hack.

Master Yoda: A small linux virtual machine to make good computer simmulation

In The Empire Strikes Back, Luke Sywalker is send to the planet Dagobah by his first mentor spirit, master Obi-Wan Kenobi, to meet Obiwan’s mentor, Master Yoda. Luke’s first impression after knowing Yoda was of surprise, not because of Yoda’s skills, but due to Yoda’s look. He was a small green elder, with a peculiar way of talking, living in a swamp in the middle of nowhere. However his look, master Yoda was the greatest Jedi of all times.

Back on earth, in my programming curse in Mexico, students are expected to learn how to program in a higher level language, and being prepared to solve basic problems in numerical computing after this curse. Being the instructor, my main task is to teach a good programming language to a fairly big classroom for Mexico’s college standards (about 35 students). This term, I chose to use python instead of the more traditional matlab, given the difficulties that students have on getting the software for their personal computers, and the limited number of licenses that my school holds.

My first impressions teaching this way are rather positive. My students have learned quite easily python’s basics, and in the beginning we where working with  aptana in computers running ubuntu at the computer lab. Problems came when the students tried to install python in their own boxes running windows. Certainly, these problems where very easy to solve (apparently), because most were related to configuring the Windows path. Nevertheless, having 35 students with computer related problems, plus their mid term projects was big deal.

Being a linux guy, with fairly good experience in arch linux, and being arch very configurable, I decided to solve this issue once and forever. This weekend I decided to solve this question:

What are the minimum system requirements to have a virtual machine running python with the needed libraries to work on numerical problems?

As I expected, the answer was that I needed a very slim system. The final virtual machine was only 1.9GB, which meant that my students can take it with themselves home in their pendrives, and that they needed only 256MB or less of precious RAM to run (I tested as low as 128MB in my linux box at home).

In a future post, I will show how I did this, and elaborate more on how customisable arch can be, but for the time being, let me finish this post with some humor that expresses why I think it is important for my students to develop the basic skills in this course the “right (unix) way”:

Perl vs Python (this funny story is not only about perl and python, the author’s introduction reflects quite well what I call the Unix way.)

Intalling gtk2 theme engine in HOME directory

I wrote this post because I installed various gtk theme engines in my $HOME, and every time I tried to use them with eclipse, I received this warning:

  • Gtk-WARNING **: Unable to locate theme engine in module_path: “clearlooks”

I knew I could install everything in /usr as usual, but I was decided to resolve my problem the hard way. First I tried the “obvious” thing: setting LD_LIBRARY_PATH to $HOME/lib, which is where I installed the theme engines without success. Google did not give me an easy answer to what to do neither. Most answers to the warning where about installing some gtk engine packages, which I had decided to avoid, or about setting LD_LIBRARY_PATH, which did not solve my problem. After countless forum solutions read, I realized that what I needed to know was what Gtk expected that module_path be, which I found here:

Finally, these are the steps I needed in order to use eclipse, or any other gtk+ application, with gtk themes (Clearlooks in my case).

Assuming that gtk theme engines are installed in $HOME/lib/gtk-2.0/2.10.0/engines, there are two options:

  1. Setting GTK_PATH before invoking eclipse.
  2. Creating a symbolic link to gtk module_path.

For the first option, type in a terminal:

> GTK_PATH=”$HOME/lib/gtk-2.0/2.10.0/engines” eclipse

For the second option, type:

>ln -s “$HOME/lib/gtk-2.0/2.10.0” “$HOME/.gtk-2.0”

and then invoke eclipse, or whatever program using gtk+, as usual.