Re: [evolution-patches] Bug 21974: Make editor component configurable
- From: Jason Hildebrand <jason peaceworks ca>
- To: Not Zed <notzed ximian com>
- Cc: Jeffrey Stedfast <fejj ximian com>, evolution-patches lists ximian com
- Subject: Re: [evolution-patches] Bug 21974: Make editor component configurable
- Date: Fri, 09 Jan 2004 10:29:27 -0600
On Thu, 2004-01-08 at 20:35, Not Zed wrote:
> looks good.
> the only problem i have with it is what happens when the editor
> version
> changes? you would be left with the configuration value that was
> previously saved pointing to the wrong thing. or is the assumption
> that
> since its hidden, if you change it its your own fault?
That scenario had crossed my mind as well. My original thinking was
that the user just has to deal with it themself, as they were the one
who messed with the key in the first place. Since it's the power users who
will be changing editors, they can probably figure it out.
However, here are two ideas for how we could reduce the impact of the problem.
1. Embed a version number in the gconf key. I.e. instead of looking for the
key "editor_oafiid", we look for "editor_oafiid_1". This number can then
be bumped whenever the default OAFIID is bumped.
CONS: - gconf pollution
- power users get their editor set back to default whether or
not they want
2. Having the key set to the wrong version will likely manifest itself in not
being able to instantiate the editor component. If the instantiation fails
we could check if the gconf key differs from the default. If it does we could
pop up a dialog and offer to reset to the default editor (i.e. delete the
key).
CONS: - would not catch the problem if the previous gtkhtml version is
still installed
I don't know if either of these ideas would help all that much -- I think
I'm still inclined just to leave the problem up to the user.
Thoughts?
peace,
Jason
--
Jason D. Hildebrand
jason peaceworks ca
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]