Real ThinkPad keyboards (not this monstruous ignominy) have directly accessible keys for XF86Back and XF86Forward. That is really problematic with web browsers such as Firefox or Chromium since pressing those keys transparently go back or forward into your history, discarding anything you were typing in the process, including that 3 hours long bug report you were just about to submit. That’s rather annoying, to say the least.
Some other blog post suggest to simply disable them with xmodmap. That is in ~/.xmodmaprc (or whatever it is you use):
keycode 166 = NoSymbol
keycode 167 = NoSymbol
I personally prefer to remap them to Next/Prior keys. Having these near the navigation keys might come up handy:
keycode 166 = Next
keycode 167 = Prior
That’s on Linux though, on FreeBSD the keycodes are 233 and 234:
keycode 233 = Next
keycode 234 = Prior
Anyway use the xev command and xmodmap -pke to find the keycodes and remap them to any other interesting key symbol.
Since several weeks now I had a problem with chromium. The web browser segfaulted on launch until I ran xfsettings. This daemon configures desktop settings for the xfce desktop. It listens to xfconf and uses the xsettings protocol to propagate configuration changes on-the-fly. So you can use xfce4-settings-manager and rely on the xfce configuration mechanism to change your desktop settings nicely. Actually I used that to easily change the GTK and icon themes.
This is great for fully integrated desktop environment as it gives you a shiny graphical interface that “just works”. However it doesn’t work so much when you modify much of your configuration by hand.
For example, I use a script which listens to changes in the VGA output port and uses xrandr to setup the screen accordingly. But no matter what, if I start xfsettingsd after the initial configuration, it resets everything to whatever xfce thinks my screen configuration should be. And since I didn’t told him, it has no clue. The same apply for the keyboard, for which I use the device name to select the layout (dvorak/azerty/qwerty). The daemon just resets the layout, and worst of all, enables numlock. But again, it has no clue.
So I decided not to use xfsettings anymore. But as soon as I did that, the chromium web browser did not want to start. It even segfaulted, which is bad, but anyway. I guess the problem was a misconfigured gtkrc (well… xfce wasn’t there to hold my hand anymore) which for some reason made chromium go completely nuts. So I fixed this by using LXAppearance to generate a more complete gtkrc which I modified by hand aftewards.
In fact, the actual problem was the gtk-font-name that missed an explicit font family. In other words, in my gtkrc, I had this:
Today I was surprised to see a GTK-3 application opening an HTTP URL with Opera. I don’t use Opera and I just installed by curiosity long ago and forgot about it. I configured the Debian alternatives however GTK-3 seems to use xdg-mime as confirmed with an strace of the concerned application and references to /usr/share/applications/defaults.list. Note that you may have to create a symlink for defaults.list to /usr/share/applications/mimeapps.list.
You can use the xdg-mime command to configure the default application for each protocol: