So I keep ranting about Firefox here, and for good reason: the Mozilla team is going above and beyond the call of duty when it comes to driving users to other browsers.
However, try as I might, I simply encounter too many dealbreakers in Chromium.
When I think about it, the last version of Firefox that didn’t drive me crazy with crashing, incompatible add-ons, and stupid UI changes and features removed, it would have to be Firefox 3.6.
I keep forgetting how to do this, so I’m posting this here as much for my own reference as for anyone else’s. This is how to downgrade newer versions of Firefox to 3.6 and keep it that way, at least until things settle down a little, or until another browser comes along that can actually be a viable replacement for it — unlike newer versions of Firefox, sadly. This works with Mint 11, which means it will also work with Ubuntu 11.04.
For the last year and some change, I’ve gone from using Opera as my primary browser to using Mozilla Firefox. I have a variety of reasons for this switch, and it was a somewhat gradual one, but as I detailed in a recent post, despite it being my browser of choice, I still feel that it has a lot of shortcomings, and as such, it needs a lot of tweaking out-of-the-box before I find it usable.
So this is a writeup of the things I do to Firefox — in this particular case Firefox 4 — immediately after I install it. It used to be a much shorter list, but these days it’s getting more and more involved, so this writeup is as much for my own purposes, as a checklist of sorts, as it is to share my thoughts with others on how to tweak Firefox 4.
A few weeks ago I posted a very early review of the new web-friendly Peppermint OS. In that review, I lauded the Peppermint team for achieving what I think might be the fastest graphical Linux distro I’ve ever tried, on any hardware.
The only things that get in my way of enjoying Peppermint are, unfortunately, the limitations imposed by the still-under-heavy-development LXDE desktop environment, which, while I’m still pretty excited about it, provides a few stumbling blocks to someone like me who likes to have more control over his user interfaces.
Well, for those of you out there who agree, I thought I’d do a quick writeup on getting the most out of Peppermint OS without having to resort to installing another desktop or window manager. Instead, we can make do with something that’s already integrated into Peppermint: the Openbox window manager!
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.