One of the beautiful things about Linux is that developers tend to be conscientious about the use of technical standards. Freedesktop.org maintains a wide series of standards for X Window System desktops, which apply to Gnome, KDE, LXDE and XFCE (I’m not sure whether Fluxbox implements these standards.) The standard for “desktop entries” is still technically a draft, but is generally accepted by the larger X community.
The .desktop file fills two primary functions: first, it informs the desktop environment how the file is to be handled by the desktop environment with regard to menu placement, display, environmental variables, and similar. In this function, it resides globally in /usr/share/applications/ and for specific users in $HOME/.local/applications. The second function is the direct shortcut on the desktop itself. In this function, it resides in $HOME/Desktop. The same file fills both functions, so if you want to have an application both in the menu and on your desktop, you’ll need to put the .desktop file in two places. Let’s take a closer look, shall we?
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.