StarDict. Customizing dictionary entry colors.

I use StarDict. StarDict is more or less good dictionary program for Linux (in fact, it runs not only on Linux). It’s not perfect but it’s fairly good and even has some interesting functionality, scan selection for instance. You select a word anywhere where it is selectable and then press hot-key combination and a nice little window emerges on your display right besides your current cursor position. Very convenient when you read web-pages, or e-books, or what not. You can even convert the famous Lingvo dictionary and use StarDict as a front end. This brings a powerful dictionary to Linux and other platforms.

One thing that really irritates me in StarDict, and I mean it, it’s the colors choice for dictionary entries elements. By default StarDict comes with ultra light green and violet colors. Given most UI are bright colored it still remains a secret for me why developers decided to choose violet and ultra light green as default colors AND not give us any other options. Oh, I hate those colors on my bright gray canvas!

So, one day I realized I couldn’t take this anymore and I had to do something about it so I started figuring out and eventually I raised the question on StarDict forum. Thankfully, some kind people gave me a hint.

At that moment in time I was involved with Source Mage GNU/Linux. It’s a wonderful rising distro that sports a very cool sorcery package management and build system. It works almost like magic at times. So, when I figured out how to change colors for StarDict dictionary entry colors I scribed a spell. Nope, I’m not a wizard, only an apprentice. The result of my work can be found here: sourcemage/grimoire/codex/stable/spelling/stardict/PRE_BUILD

Note the following code:

sedit "s:violet:darkgray:" tests/t_articleview.cpp &&
sedit "s:violet:darkgray:" stardict-plugins/stardict-xdxf-parsedata-plugin/stardict_xdxf_parsedata.cpp &&
sedit "s:green:brown:" tests/t_articleview.cpp &&
sedit "s:green:brown:" stardict-plugins/stardict-xdxf-parsedata-plugin/stardict_xdxf_parsedata.cpp

this is what does the magic. The sorecery politely asks a user if she wants the colors of a StarDict dictionary entry be changed from extremely light to more serene before the spell is built. Nice. IIRC, sedit isn’t a real program but some sort of BASH construct (probably a function) that wraps sed and allows for simpler use of this tool in sorcery scripts… ahem.. that is spell manuscripts.

Okay, so you probably get the idea already. You can just grep recursively the StarDict’s source code tree and see if these colors – green and violet – are used somewhere and then you can change those to whatever you like (use any of these colors [1]) and see how it looks when you recompile the program.

Well, Source Mage guys were lucky to have me freaking out over this issue. How about your favorite distribution? Honestly, I have no idea. These days I run Arch Linux and it ships StarDict with green and violet colors. Ugh. I had to rectify the situation yet again. And here’s a verbatim copy of commands I used to build a custom package that eventually would look like in this illustration (the latter screenshot, compare to green-violet hideous color combination *wink-wink*):

This is how the default StarDict looks like. Hideous (subjectively, of course!) green and violet.

And this is my idea of a good color choice. I call this color scheme “Serene”. You can look at more examples [2].

And here’s the code. First, sync abs. Okay, first install ABS. No, perhaps first read about ABS, then install it, then sync 🙂

root@sega:/home/ilj % abs
...
ilj@sega:/home/ilj % cp -a /var/abs/extra/stardict/ ~/builds/abs/
ilj@sega:/home/ilj % cd ~/builds/abs/stardict/
ilj@sega:/home/ilj/builds/abs/stardict % lsh
total 36K
drwxr-xr-x 2 ilj ilj 4.0K Apr 15 07:08 .
drwxr-xr-x 3 ilj ilj 4.0K Apr 15 20:00 ..
-rw-r--r-- 1 ilj ilj 1.3K Apr 15 07:08 gtk_gthread_fixes.patch
-rw-r--r-- 1 ilj ilj 1.2K Apr 15 07:08 PKGBUILD
-rw-r--r-- 1 ilj ilj 7.3K Apr 15 07:08 sigc++.patch
-rw-r--r-- 1 ilj ilj 12K Apr 15 07:08 stardict_gcc43.patch
ilj@sega:/home/ilj/builds/abs/stardict % vim PKGBUILD

So, here you open PKGBUILD and add the following block of code

sed -i -e "s:violet:darkgray:" tests/t_articleview.cpp || return 1
sed -i -e "s:violet:darkgray:" stardict-plugins/stardict-xdxf-parsedata-plugin/stardict_xdxf_parsedata.cpp || return 1
sed -i -e "s:green:brown:" tests/t_articleview.cpp || return 1
sed -i -e "s:green:brown:" stardict-plugins/stardict-xdxf-parsedata-plugin/stardict_xdxf_parsedata.cpp || return 1

right after the patches and before the configure is invoked. Save the changes and exit the editor. Then run

ilj@sega:/home/ilj/builds/abs/stardict % makepkg -s
ilj@sega:/home/ilj/builds/abs/stardict % su
Password:
root@sega:/home/ilj/builds/abs/stardict % pacman -U stardict-3.0.1-3-i686.pkg.tar.xz
loading package data...
checking dependencies...
(1/1) checking for file conflicts [###########################################################################################################################] 100%
(1/1) upgrading stardict [###########################################################################################################################] 100%
root@sega:/home/ilj/builds/abs/stardict % exit

Now run `stardict‘ and never see those so violently light colors again.

There are a couple of things we could do to make dictionary entries look even better. I personally dislike “<—” and ” —>” around dictionary name so I decided to get rid of these. Simply add the following line to PKGBUILD:

sed -i -e "s:& l t;-* ::g" -e "s: -*\& g t;::g" src/articleview.cpp || return 1

Note that “& l t” and “& g tMUST NOT contain spaces in between the three symbols. I had to add additional spaces so that WordPress doesn’t interpret them as “” HTML codes.

Also, after several years of using StarDict I’ve always felt there was something wrong with the way the data was presented. Except the obvious – colors – I found that the dictionary names following right after the last line of the preceding dictionary entry contents gave me a feeling of inconvenience. I figured that adding one more blank line after the end of the contents of any given dictionary entries creates more space that is visually very easy to catch and follow. While this may seem very trivial a mere additional empty line allowed me to navigate large lists of search results with multiple dictionary entries easier and faster. After all, there are highly paid professionals whose job is to improve various things – from furniture and car design to UI design and web-sites usability – by being creative, analytical and meticulous. Often what they do is tweak seemingly senseless things, like adding an extra space or making sure some things are small while other ones are big, which proves very important eventually. I highly recommend that you add the following sed line to your PKGBUILD, you might just like the results in the long run:

sed -i -e "s:append_pango_text(\"\\\n\");:append_pango_text(\"\\\n\\\n\");:g" src/articleview.cpp || return 1

The result of the two above sed commands will look like this:

Notes:

[^ 1] – Note that some colors can be referred to by their names, like darkgray, green, violet, etc. If you used a color name and it didn’t work right (you’d see no usage examples in a dictionary entry at all) simply use hex color value equivalent, i.e. #808000 for Olive and so on.

[^ 2] – More examples of good looking color schemes for Stardict:

Teal, #008080

OrangeRed, #FF4500

Olive, #808000

ForestGreen, #228B22

Deleting recent addresses in KMail

Removing recent addresses is a feature hard to discover in KMail yet very useful one. If you’re a user of this e-mail client you know well that KMail stores all addresses you e-mailed to in a recent addresses list. The problem arises when you make typos and over time the number of wrong e-mail addresses build up to the point of irritating the hell out of you. As it turns out it is not very easy to discover a way to edit this list, but it is possible… *drums* To delete entries from a recent addresses list you need to put your cursor onto To:/Cc:/Bcc: input line and do a RMB click, then choose “Edit recent addresses…” in the context menu. That simple yet hard to discover.

sshfs for normal users

Hey there. So it looks like this is going to be my first real post here and I’m going to talk about sshfs. sshfs (with the help of fuse) allows for simple, rather rudimentary network filesystem. The idea is very simple mount a remote directory on your local computer and make access to that remote directory transparent, i.e. as if it is a local one. sshfs itself is very straightforward and simple, simply run man sshfs and you should be able to do basic stuff. One thing that bothered me for some time was that for some reason I couldn’t use this network mounts over ssh as a normal, unprivileged user. Whenever I attempted to mount a remote folder on a remote computer and map it to a local one accessing this new mount as a normal user would always result in something very similar to this:

% id
uid=1000(ilj) gid=1000(ilj) groups=1000(ilj),91(video),92(audio),100(users)
% lsh /mnt/
ls: cannot access /mnt/hostname-photos: Permission denied
total 40K
drwxr-xr-x  5 root root 4.0K Apr  4 17:10 .
drwxr-xr-x 20 root root 4.0K Mar  1 18:16 ..
d?????????  ? ?    ?       ?            ? hostname-photos
drwxr-xr-x  2 root root 4.0K Mar 16 17:36 tmp
dr-x------  1 ilj  root  28K Feb  2 07:57 vista

The real problem here is that instead of seeing valid permission and ownership information for hostname-photos directory we’re observing an odd array of question marks.

I’m lazy as hell. I postponed figuring this issue out as much as I could… until today. Facing an absolute need to map remote directories to local filesystem I finally found a solution. The solution is using mount options. Since my setup won’t be changing much I decided to create a fstab entry:

/etc/fstab
sshfs#username@hostname:/home/username/photos /mnt/hostname-photos fuse defaults,users,reconnect,allow_other 0 0

This is exactly what made possible access for normal users. Use it.

Mount and umount  as root user your new mount point.

% mount /mnt/hostname-photos
% umount /mnt/hostname-photos

Use mount to see how your mount points are doing

% mount |grep sshfs
username@hostname:/home/username/photos on /mnt/hostname-photos type fuse.sshfs (rw,noexec,nosuid,nodev,max_read=65536,allow_other)