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
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.
[ 22:22 Jun 27, 2005
More linux |
permalink to this entry |
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
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):
(obviously, pick any pair of colors which strikes your fancy).
[ 21:45 Jun 27, 2005
More tech/web |
permalink to this entry |