Regular visitors to this site will know that Fluxbox is Trent’s and Patrick’s preferred window manager. I, too, am impressed with its speed and customizability, and its low overhead. Fluxbox’s biggest drawbacks are that customization is somewhat less intuitive and significantly more labor-intensive than the full-featured environments’, and that the interface as a whole is foreign and unintuitive to those whose only other computer experience has been Windows.
A while ago when I upgraded my distribution, several keys went wonky on me and ceased functioning according to my wishes. It was a minor inconvenience to have things like the Caps Lock key become enabled again. So I pecked around at fixing it here and there, but never really put in much thought or effort until today.
I remap my keys with the /etc/X11/xinit/.Xmodmap (aka ~/.Xmodmap) file. The problem was my .Xmodmap was borking when X started, so no remappings were taking place. (If one part of .Xmodmap fails, they all fail.) In my /var/log/Xorg.0.log I found this:
(EE) Error compiling keymap (server-0)
(EE) XKB: Couldn't compile keymap
(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
And in the output from X – apparently from the keymap compiler (xkbcomp) – were repeated warnings/errors like this:
Warning: Duplicate shape name ""
Using last definition
Error: Section defined without a name
Warning: Multiple doodads named ""
Using first definition
Over at The Complete Geek my friend Jered posted a really nice howto on remote X11 forwarding the other day.
Like many of the uses of Synergy, remote X can be extremely useful when you’re working with multiple machines, or even if you’re working with a virtual machine and need to run some of the applications on the host without constantly flipping windows back and forth. One other useful application of remote X can be if you’re using a machine low on resources, it can act as a terminal of sorts, running remote X applications from other workstations.
Jered also points out how useful it is if you’re standing with one foot in the Windows world and one foot in the Linux world, because remote X can make that easier as well.
Give it a read, it’s a great writeup. The post can be found here: Remote X11.
Fluxbox is a window manager about which I have written a lot. The reason for that is because I use it every day, and I like it a lot. There’s a lot to like. It’s lightning fast, stable, and tweakable to a degree that will satisfy nearly every tinkerer when it comes to window managers.
But one of the biggest barriers to adopting Fluxbox for the “less tinkery” users out there is its configuration learning curve. Yes, Fluxbox is pretty simple when you get over the fact that you have to edit several configuration files by hand to set up your menu, your keys file, and other aspects. But for many users this is a big deal.
For some of those users, the answer to that dilemma is Fluxconf, a package of three applications that can be used to configure Fluxbox graphically.
A good friend of mine and fellow technology wizard has on several occasions brought up Synergy as a great solution for doing work spanning a couple of local workstations.
I know I have several times added it to my “Mental List Of Apps To Try”, but somewhere along the way I forgot about it. Last weekend Jered was over at my house for dinner and he brought it up again, and this time I installed it.
To make a long story short: I should have been playing with Synergy a long time ago!
For those who like to read a little bit more than that, continue, because I have a writeup.
I am always on the lookout for a new way of doing things when it comes to personal computing, and one of the best ways to do so is to experiment with different window managers for Linux.
Since I have my laptop set up as an Ubuntu test platform, and since APT makes it easy to download and install applications and not find myself in dependency hell, my laptop seemed to be a great way to play around with a window manager about which I’ve been reading for some time: Openbox.
Those of you who are familiar with LXDE will have some experience, albeit limited, with Openbox, as LXDE is based on it (with a bunch of other cohesive applications and a consistent look and feel integrated to complete the transition from “window manager” to “desktop environment”), but Openbox will seem much more familiar to users of Blackbox and Fluxbox, predominately in the sense that Openbox is built very light and minimal, with a desktop bare of icons, and a user-defined right-click menu that is used for launching applications. Like Blackbox and Fluxbox, Openbox is also dockapp friendly, and as a window manager it runs very fast on limited hardware.
I’m a big fan of Fluxbox, so I thought it worthwhile to give Openbox a try, if nothing else to give me material for a Linux Critic writeup, and instead I found that I just liked using Openbox, so this turned out to be more than just a review.
So a few days ago, Slackware 13.0 was released. Unfortunately, Patrick Volkerding greatly deviated from the basic philosophy to which he’s faithfully adhered for years with nearly every release — one of stability, simplicity, and only including elements in the distro that are thoroughly tested and functional — and replaced the highly stable, robust, and fully tested KDE 3.5.10 with the much less stable, buggy, half-baked and in fact barely usable KDE 4.2.4.
I wrote the other day that I considered this a minimum of a year or so premature, and had decided sight unseen that this was a bad decision, based on my extensive attempts at using KDE 4 releases as recent as 4.3 (on OpenSUSE 11.1).
Turns out I was right. KDE 4.2.4 on Slackware 13 is a disaster. I did a full install of Slackware 13 last night on VirtualBox and found KDE 4.2.4 to be just as unusable on Slackware as I had found it to be in Kubuntu when I tried it out a couple of months ago. Not surprising, since I didn’t expect that Patrick would have been fixing the massive usability issues intrinsic to KDE 4 just by including it in a Slackware release; that just isn’t a realistic expectation. Still, I had to get a baseline, and that baseline was about what I had expected.
Then, I set about finding a way to upgrade KDE 4.2.4 to KDE 3.5.10 on Slackware 13. I was successful in this today, and here is my writeup of how I did it.