Re: [evolution-patches] spell prefs in evo/mail

[Not Zed <notzed ximian com>]

On Wed, 2003-06-25 at 18:11, Radek Doulík wrote:
> On Wed, 2003-06-25 at 04:22, Not Zed wrote:
> > Sigh, you didn't give me time to disagree with this patch.
> 
> I am sorry, I though approval from Jeff was enough.

As far as i remember, 24 hours to register objections from core
maintainers was always the rule.  It wouldn't be so bad if it wasn't for
the timezone thing.

> > I have serious issues with this:
> >  
> > +    <schema>
> > +     
> > <key>/schemas/apps/evolution/mail/composer/spell_copied_from_old_location</key>
> > +     
> > <applyto>/apps/evolution/mail/composer/spell_copied_from_old_location</applyto>
> > +      <owner>evolution-mail</owner>
> > +      <type>bool</type>
> > +      <default>false</default>
> > +      <locale name="C">
> > +         <short>spell preferences are copied from an old
> > location</short>
> > +         <long>
> > +        spell preferences are copied from an old location
> > (/GNOME/Spell)
> > +         </long>
> > +      </locale>
> > +    </schema>
> > 
> > 
> > All I can say is, WTF?  What sort of nonsense is this ???  The config
> > data is already versioned, and besides that, you can easily discover it
> > has been copied by implicit reasoning (i.e. if the new location exists
> > ... its been copied).
> 
> The reason for that change was to have default for spell error color in
> gconf. AFAIK I can't tell if value from gconf is schema default or

Well, yes quite ... i have no problem with the new value being in gconf,
it makes sense (assuming you want to make the setting different for
evolution/mail vs anything else that uses it), just how it's getting
there.

> actual value. The other benefit is avoiding additional gconf round-trips
> for /GNOME/Spell directory. That's why I did it like this.

> What do you dislike on that approach so much? The visibility of copied
> flag in gconf-editor?

Because the flag doesn't fit or belong in gconf.

We already have a versioned evolution config tree, and this is just a
versioning issue, and a particularly messy solution to it (how would it
look if we did this every time something changed?).

Since gconf doesn't let you lookup non-existant values (ahh what a great
api gconf is), then i guess you need to move the code into
e-config-upgrade.c and bump the evolution config version (also in that
file).  It should be easy to move there (it even has comments).

> > Might be a nice idea to clean up the GET macro stuff too.
> 
> I will use the G_STMT_START/G_STMT_END macros if that's what you mean
> and/or rename it.

Well i was more thinking remove it.  It doesn't add anything that
couldn't be done with a function, and only makes the code harder to
follow.