Archive | May 2013

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.