Shallow Thoughts : : 27

Open Office Losing Its Mind

I needed to use OpenOffice today, and got a nasty surprise: it no longer remembered any of my settings, key bindings, or any of those painfully-installed templates I'm required to use for this project.

It turns the version of OpenOffice.org I pulled in with the last Sid upgrade, 1.1.4, has a nifty new feature: it has no knowledge of the ~/.openoffice/1.1.1 directory its predecessor used for its configuration, and instead wants to use ~/.openoffice/1.1.0. Does it notice that there's an existing config directory there, and offer to migrate it? No! Instead, it silently makes a new 1.1.0 directory, with all-default settings, and uses that. The effect to the user is that all your settings and templates have suddenly disappeared for no obvious reason.

The fact that the new version uses a seemingly older version number for its configurations is a nice twist. Perhaps they were worried that otherwise some enterprising user might figure out what had happened, and actually recover their settings, rather than wasting hours painfully resetting them one by one.

Aside: it's impressively hard to read OOo's settings to figure out which ones might be yours. For example, here's a sample line which binds Ctrl-H to delete-backward-char:

 <accel:item accel:code="KEY_H" accel:mod1="true" xlink:href="slot:20926"/>

(You can still tell it involves the "h" key somehow. But I bet they're working on purging that shameful bit of human readable information.) That adds a touch of extra spice to the challenge of figuring out which set of files is the right one.

Anyway, if this happens to you, move the 1.1.0 directory somewhere else, then rename or cp -a 1.1.1 to 1.1.0. That seems to bring back the lost settings.

Tags: linux, open office
[ 22:22 Jun 27, 2005    More linux | permalink to this entry | ]

Catching Up on Firefox Regressions

I spent a little time this afternoon chasing down a couple of recent Firefox regressions that have been annoying me.

First, the business where, if you type a url into the urlbar and hit alt-Enter (ctrl-Enter in my Kitfox variant) to open a new tab, if you go back to the old tab you still see the new url in the urlbar, which doesn't match the page being displayed there.

That turns out to be bug 227826, which was fixed a week and a half ago. Hooray!

Reading that bug yielded a nice Mozilla tip I hadn't previously known: hitting ESC when focus is in the urlbar will revert the urlbar to what it should be, without needing to Reload.

The other annoyance I wanted to chase down is the new failure of firefox -remote to handle URLs with commas in them (as so many news stories have these days); quoting the url is no help, because it no longer handles quotes either. That means that trying to call a browser from another program such as an IRC client is doomed to fail for any complex url.

That turns out to be a side effect of the check-in for bug 280725, which had something to do with handling non-ASCII URLs on Windows. I've filed bug 298960 to cover the regression.

That leaves only one (much more minor) annoyance: the way the selection color has changed, and quite often seems to give me white text on a dingy mustard yellow background. I think that's because of bug 56314, which apparently makes it choose a background color that's the reverse of the page's background, but which then doesn't seem to choose a contrasting foreground color.

It turns out you can override this if you don't mind specifying a single fixed set of selection colors (instead of having them change with the colors of every page). In userChrome.css (for the urlbar) and userContent.css (for page content):

::-moz-selection {
  background-color: magenta;
  color: white;
}

(obviously, pick any pair of colors which strikes your fancy).

Tags: tech, web, mozilla, firefox
[ 21:45 Jun 27, 2005    More tech/web | permalink to this entry | ]