The two most common ways to achive persistent configuration for your X programs are to store them in either ~/.Xdefaults or ~/.Xresources files.

I will not go into detail of the syntax of these files. However, there are some things to take into consideration between the choice of the two files.

Consider the X program xterm. You want to make the background black and the foreground white. This can be achived by passing some command line arguments to xterm:

$ xterm -bg black -fg white

This is fine if you want this for only one time, but if you want it to be the default you put it in a configuration file.

XTerm*background: black
XTerm*foreground: white

If you put this in the ~/.Xdefaults file you will notice that the next time you start an xterm it has the new colors. Great! Or, is it?
It is easy to change configuration options and it will be in effect next time you start the program, but it comes at the cost that basically all X programs needs to parse this file everytime you run one.

A better way is to put the configuration options in the ~/.Xresources file and store the configuration in the X server’s resource database by using the xrdb command:

$ xrdb -merge ~/.Xresources

Doing this, (in simple terms) xterm will “ask” the X server for its resource options rather than reading a file. This is much quicker and avoids unnecessary reads on disk.
Another great thing about this is that remote X programs (e.g., tunneled through SSH) will be able to catch these options.

Once configurations are read into the X server’s resource databse (using xrdb), X programs should not look for configuration options in ~/.Xdefaults file.

As many desktop environments (like Gnome or KDE) will store the configurtion from both files into the resource database upon the start of X, the drawbacks stated above may not be a problem.
However, if you don’t run a desktop environment (like me) you need to manually run xrdb when starting X (e.g., by adding xrdb command line above to the ~/.xinitrc file).

If you run xrdb manually, you can of course name the ~/.Xresources file whatever you want, but it’s the defacto standard.

Then I found out about Xephyr, which basically is an X server which targets a window of another X server as its framebuffer. Making it possible to run a window manager inside of another window manager, for instance.

Xephyr is a great tool to use even if you’re not developing. For instance, it could be used to try out different kinds of window managers. There are quite many out there worth taking a look at.

Anyway, it can be a bit tricky to get Xephyr running if you’re not all that into how X works, so I’ll save you the hassle and tell you how I used it.

I wrote a wrapper script called xephyr (note: small “x”) which simplified the usage, having the options I always want to use.

#!/bin/sh

DPY=":1.0"
RES="1024x768"

Xephyr $DPY -ac -kb -screen $RES "$@"

Some explanation:

• DPY variable is the name of the display for the Xephyr session. You will need it later on in order to attach an X application to your Xephyr session
• RES variable is the resolution for the Xephyr session, i.e., a window with that resolution will be created
• -ac argument is for disabling access control restrictions, which isn’t really necessary when experimenting. It saves us a lot of hassle
• -kb argument is for disabling the X keyboard extension. This allows you to use any key binding within your Xephyr session
• The "$@" will allow you to add additional arguments to Xephyr through the wrapper script. See Xephyr -help for more options

Save the script to a directory which is in your PATH (e.g., /usr/local/bin or ~/bin), and don’t forget to chmod it (chmod +x xephyr).

Now, in order to start Xephyr just execute the wrapper script (it will run in the foreground of your terminal, and will output information from the Xephyr session which might be useful if you’re developing):

$ xephyr

At this moment you will have a window which contains an empty X session. So, what we need now is to attach a window manager to it. That is done by starting the window manager (in my case wmii) with the environment variable DISPLAY set to the display the Xephyr session is using (in our case “:1.0″):

$ DISPLAY=":1.0" wmii

If the window with the Xephyr session has focus, it will pass on most keystrokes to that session, but the window manager inside of Xephyr might have key bindings which could collide with your real window manager (if so, they will get overridden by the real one). To exclusively use keyboard and mouse within the Xephyr session, press CTRL+SHIFT (i.e., press CTRL first, then also press SHIFT). That will allow Xephyr to grab all keyboard and mouse events (CTRL+SHIFT will also release it).

That is all. Happy experimenting! :)

It has now been quiiite a while since my last (and only) post, and after a couple of pushes from my friend wildcard I’ve decided to give this blogging thing another go.

There is always some cool things that you learn along the road that is worth telling about. I just need to take the time to write them down in order to share them :)

I already got a couple of ideas of some topics that I want to write about, and wildcard has been kind to give me a couple of hints as well. So, stay tuned, there might pop-up some posts in the near future (and by future I do not mean as in ~2 years… I hope ;))

P.S. For you who did not get the initial reference, it’s from the “End of the World” flash movie. D.S.

If your answer is yes in any of these questions, then this post might be of interest to you!

Pidgin message dialog with bloated OTR button

Background:
Since I got tired of that bloated button I decided to investigate if it would be possible to resize and/or move it somewhere else, where it wouldn’t be as easy to hit by accident. And since there were no configuration for doing that, I started to look at the source code for the plugin and managed to find where in the code the button was actually rendered. (I know that you can remove the OTR button from a contact by having specific OTR settings on that specific contact. First of all, I think it would be tedious to do that for every contact you don’t use OTR with. And secondly, contacts that I DO use OTR with, I’d still have that bloated button in my face ;))

What I did:
I removed the icon, since I thought it was just ugly and taking space. But instead of an icon, I color coded the different OTR status types. (Thank you for the great suggestions, wildcard :))

Finally the button was moved to the right in the formatting toolbar. Yes, I know this might not be the nicest… whatever, but I had a hard time trying to get it to be any good by doing it different. The problem was that if I wanted it to be on the right hand side of the message input area, I guess I’d also need to change some the pidgin source, because it seemed that the message input area was rendered with right alignment after the OTR button was rendered, and thus the OTR button would still end up being on the left hand side of the message input area. I’m not sure if that’s the case, but it seemed to be that way. And to start hacking on the pidgin source, would probably only complicate things even more.
Anyway, even though I don’t use formatting myself, it was a small price to pay :)

The result:

Pidgin message dialog with a bit cleaner OTR button

How you’ll do it:
Obviously, you will need the pidgin-otr source to apply this patch. And this patch is for version 3.1.0. If you have any of the previous OTR plugins installed, or version 3.1.0 installed from your package manager, it must be uninstalled first.
(Note! You will need the OTR library and toolkit (libotr) to be able to compile pidgin-otr. Further information about OTR setup at http://www.cypherpunks.ca/otr/)

1. Standing in your pidgin-otr source folder, execute the following if you have OTR currently installed
   

   $ sudo make uninstall && make clean

2. Download the patch into the source folder
   

   $ wget http://blog.pesa.se/files/pidgin-otr-3.1.0.patch

3. Before you apply the patch, you might want to backup the original file
   

   $ cp gtk-dialog.c gtk-dialog.c.bak

4. Apply the patch
   

   $ patch -p0 < pidgin-otr-3.1.0.patch

5. Finally, compile and install it
   

   $ make && sudo make install

And you’re done!
Happy private messaging in cyberspace :)