Desktop tweaks

This post is just a list of some of the desktop tweaks I did to help me set them up again if needed :)

Change Ctrl-U to kill-line instead of View Source in opera

First, edit ~/.gtkrc-2.0:

binding "gtk-clear-text-entry" {
    bind "<ctrl>u" { "delete-from-cursor" (paragraph-ends, -1) }
    bind "<ctrl>k" { "delete-from-cursor" (paragraph-ends, 1) };
}
class "GtkEntry" binding "gtk-clear-text-entry"
class "GtkTextView" binding "gtk-clear-text-entry"

For gtk3:

edit ~/.local/share/themes/CtrlU/gtk-3.0/gtk-keys.css:

/*
 * Bindings for GtkTextView and GtkEntry for Ctrl-U, Ctrl-K
 */
@binding-set gtk-ctrlu-text-entry {
  bind "<ctrl>u" { "delete-from-cursor" (paragraph-ends, -1) };
  bind "<ctrl>k" { "delete-from-cursor" (paragraph-ends, 1) };
}

entry {
  -gtk-key-bindings: gtk-ctrlu-text-entry;
}

textview {
  -gtk-key-bindings: gtk-ctrlu-text-entry;
}

edit ~/.config/gtk-3.0/settings.ini:

[Settings]
gtk-key-theme-name = CtrlU

This seems to be enough for Firefox-35 and Chromium-40 and Opera-27 to use Ctrl-U in input fields.

To disable the Ctrl-U - View Source binding completely in Opera,
edit ~/.config/opera/Preferences, add/modify the Keybindings section:

"Keybindings": {
      "Basic": {
         "ForceReload": [ "Shift+F5", "Ctrl+F5", "Ctrl+Shift+R" ],
         "ViewSource": [  ]
      },
      "Settings": {
         "AdvancedEnabled": true
      }
   },

See Ruarí’s blog for more customization options in Opera.

Fix the new snap-to-client behaviour of kwin

Kwin's window snapping algorithm was changed from snap-to-deco to snap-to-client which I personally find annoying (see Bug 325286). The current workaround is to use the Screen Snapping kwin-script by Thomas Lübking...
The KDE5 version: Screen Snapping 5.

Restoring top(1) sanity

The recent versions of top(1) on linux start up with some atrocious defaults bleeding my eyes out. To get back to a sane-looking top, add these to ~/.toprc:

top's Config File (Linux processes with windows)
Id:i, Mode_altscr=0, Mode_irixps=1, Delay_time=1.500, Curwin=0
Def fieldscur=¥&K¨³´»½@·º¹56ÄFÅ')*+,-./0128<>?ABCGHIJLMNOPQRSTUVWXYZ[\]^_`abcdefghij
    winflags=192564, sortindx=18, maxtasks=0, graph_cpus=0, graph_mems=0
    summclr=1, msgsclr=1, headclr=3, taskclr=1
Job fieldscur=¥¦¹·º(³´Ä»½@<§Å)*+,-./012568>?ABCFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij
    winflags=163124, sortindx=0, maxtasks=0, graph_cpus=2, graph_mems=0
    summclr=6, msgsclr=6, headclr=7, taskclr=6
Mem fieldscur=¥º»<½¾¿ÀÁMBNÃD34·Å&'()*+,-./0125689FGHIJKLOPQRSTUVWXYZ[\]^_`abcdefghij
    winflags=163124, sortindx=21, maxtasks=0, graph_cpus=2, graph_mems=0
    summclr=5, msgsclr=5, headclr=4, taskclr=5
Usr fieldscur=¥¦§¨ª°¹·ºÄÅ)+,-./1234568;<=>?@ABCFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghij
    winflags=163124, sortindx=3, maxtasks=0, graph_cpus=2, graph_mems=0
    summclr=3, msgsclr=3, headclr=2, taskclr=3
Fixed_widest=0, Summ_mscale=2, Task_mscale=1, Zero_suppress=0

Nice, human readable config file, right? I'm not sure what special characters will be eaten by the grue during a copy-waste, so the file is available to download from here, too.

Fixing the broken line-editing in bash after a window resize

If you resize the window while you're running some program in bash (for example while editing a file in vi), bash (sometimes?) fails to update window sizes and line editing becomes completely messed up. The fix for this is the checkwinsize shell option. Just add this to your .bashrc:

shopt -s checkwinsize

Trying to get sane date formats with English locale in KDE

Ok, I don't get it why it has to be so hard...

So, KDE had a nice locale system, but they ditched it in favor of using QLocale, but QLocale is a bit lacking at the moment, so a lot of customization was lost. Now, at last they included the en_DK locale in the regional settings, but they somehow managed to botch it: the time separator in this locale is dot instead of colon, and the short date format is also some abomination, not the expected iso-date-format.

Apparently Qt supports en_SE though, which does work as I expect. Unfortunately this locale is not supported by my system (arch linux), so I had to cheat a bit: I created a symlink from the en_DK locale spec as en_SE (under /usr/share/i18n/locales), created a new entry for en_SE.UTF-8 in /etc/locale.gen and regenerated the locale database with locale-gen.

Now all is well (until the next update breaks it somehow again...)