Re: GSettings backend

[Dodji Seketeli <dodji seketeli org>]

Fabien Parent <parent f gmail com> a écrit:

>>> +    PKG_CHECK_MODULES(NEMIVERGSETTINGS, $DEP_GSETTINGS)
>>
>> We have already done this PKG_CHECK_MODULE check to determine the
>> presence of the gsettings feature and to set the CONF_MGR macro to
>> gsettings.  So doing this test here again seems unnecessary to me.  I
>> think we can remove it, as well as the assignment to the DEP_GSETTINGS
>> macro above.
>
> No we haven't already done a PKG_CHECK_MODULE. We previously used
> PKG_CHECK_EXISTS to guess automatically if we need to use GSettings or
> GConf, but this call doesn't return any error if the dependency is not
> met.

Ah, right.

>>> diff --git a/src/confmgr/nmv-conf-keys.cc b/src/confmgr/nmv-conf-keys.cc
>>> index b3f13b5..89f81c2 100644
>>> --- a/src/confmgr/nmv-conf-keys.cc
>>> +++ b/src/confmgr/nmv-conf-keys.cc
>>> @@ -27,45 +27,13 @@
>>>
>>>  NEMIVER_BEGIN_NAMESPACE (nemiver)
>>>
>>> -const char* CONF_KEY_NEMIVER_SOURCE_DIRS =
>>> -                "/apps/nemiver/dbgperspective/source-search-dirs";
> [...]
>>> -const char* CONF_KEY_CONTEXT_PANE_LOCATION =
>>> -                "/apps/nemiver/dbgperspective/context-pane-location";
>>
>> As I understand it, these keys definitions cannot be left here like
>> they were previously, because depending on whether we are using
>> gsettings or gconf, the value or these variables are not the same.  So
>> I agree with this hunk that removes the keys definition from here.
>
>> I would prefer the declaration of all configuration keys to be
>> centralized in one place: src/confmgr/nmv-conf-keys.h.  I have started
>> a progressive task of centralizing them all there, but I am not sure I
>> finished that task.
>>
>> Each confmgr backend would then have it's own definition of these
>> keys.
>
> They can stay here.
> I noticed that everything was carefully compartmentalized, e.g.
> everything (keys, schema) for the workbench was in the workbench
> folder, but this was not entirely true for the dbgperspective: only
> the schema was inside the dbgperspective folder. I deduced from it,
> that all these keys were not in the right place and should have been
> in the dbgperspective folder (that's why I moved them).
> It seems I understood the opposite of what you wanted to do, so I will
> put everything back in confmgr.

Yeah sorry.  Obviously, compartmentalizing the keys like that was a
mistake of mine.  I think using your work as an opportunity to clean up
that mess would help.  So yes, centralizing the definition of these keys
strings as much as reasonable seems beneficial to me because it will
make the work of adding a new settings back-end later, easier.  Who
knows; I heard at some point that some folks wanted to port Nemiver to
windows by using Cygwin or something like that.  Crazy.  But as Crazy
People also have the right to live and hack, we shouldn't be surprised
if they throw some patches at us some day.  (-:

>> I would even go further and say that each IConfMgr backend (gconf and
>> gsetting) should then define their own version of key variables, with
>> their own syntax; i.e for the GConf backend a key definition would be:
>>
>>    const char *CONF_KEY_ONE = "foo/bar";
>>
>> and the gsettings one. would be:
>>
>>    const char *CONF_KEY_ONE = "foo-bar";
>
> I think it would be quite redundant to do that. The base name of your
> keys are already compatible with GSettings. Why not just add the PATH,
> which would be empty with GSettings like this:
> const char *CONF_KEY_ONE = PATH "foo-bar";
> What do you think ?

I agree that this would add some redundancy in the definitions of the
key strings, but what I would ultimately want to avoid is to have
'#ifdef GSETTINGS' scattered throughout the client code.  Where would
the choice of *definition* for CONF_KEY_ONE be made, if you want to go
with the scheme you are proposing?  What would happen tomorrow when a
third backend is proposed, with a different naming scheme?

-- 
		Dodji