we currently have this slightly nebulous concept of "context" in GSettings.

Currently it is used in only 3 places:

  - creating a GSettings object ("with context")
  - keyfile stuff
  - providing your own backend

Only one of those places is "official" API.

It needs to become more clearly defined because it needs to be used for two more rather visible reasons.  The first is g_settings_sync().

The other is caused by the fact that the default dconf context is capable of bringing itself up non-blocking, but the non-default ones require blocking operations to get the PolicyKit stuff running.

Having the "with context" variant of g_settings_new block just because you provide one string instead of another is kinda unacceptable...

We could make a proper GSettingsContext object:

  g_settings_context_get{,_async,_finish} to get the non-default contexts
    - blocking can happen here

  g_settings_sync (GSettingsContext *);
    - nicer than having a string on this API

  g_settings_new_with_context (..., GSettingsContext *);
    - blocking need not happen since we already did the required work earlier

  - the "setup keyfile" API could just return a GSettingsContext *

  - the "install your own backend" API could do the same.

Two things to think about:

  - a GSettingsContext is really a GSettingsBackend.  Expose that and call it
    what it is?  This means the "install your own" API goes away entirely since
    you could just pass your backend directly to g_settings_new_with_context

  - could we just use the context name strings in place of the pointer?  In this case we can demand that you "setup" a context string before calling g_settings_new_with_context() for that same string...