[Compcomm] Settings-tool (off-topic)

[Danny Baumann]

Hi,

> > You are comparing apples and pears ;-)
> > Yes, the C API of procedural (as is C), but the Python API of it is
> > object oriented (as is Python, as is compizutil) ;-)
> I am not sure if we talk about the same kind of OOP here :D ... I doubt
> that swig-generated bindings can compete with a "human" solution. No
> matter if you write a slightly OOP-like interface-file for swig (and
> what classes does the libccs offer exactly? ...).

I know the documentation is missing ;-)
The main classes are Context, Plugin and Setting. Context contains
Plugin, which contains Setting. Also there are Conflict (for plugin and
binding conflicts), Profile (settings profiles) and Backend (for
settings backends.
A detailed documentation will follow once the API is 'set in stone'.

> Further the autogenerated code is yet another binary layer added to the
> whole process ... So like python->swig-binding->libccs->gconf instead of
> python->gconf ... :)

Umm, not exactly. In your approach only one layer is saved (libccs), so
it's python -> python-gconf -> gconf. It should not matter who wrote the
Python bindings ;-)

> > > And ccs needs its own special plugin loaded, compizutil
> > > works with the standard plugins (yes - currently only dbus).
> > 
> > But the problem begins if you don't assume dbus to be there and want to
> > transparently switch backends ;-)
> Where do you see the problem then? It's easy to find out if compiz is
> listening on dbus - if it isn't, we use gconf or another fallback. 

I mean: The fallback backend to use depends on the Compiz storage
backend used. You can't easily change backends on-the-fly.

> Dbus
> should be activated through the default settings, anyway (it _should_).
> It is only a problem of most packagers not knowing enough about it.
> Almost any gnome/kde system has dbus running by default.

I know ;-)

> > > And you are right, ccs offers more backends and maybe some more things,
> > > mostly because it is one year old and has many contributors. 
> > 
> > Umm, CCS is 3 months old and has (at least the library) exactly 2
> > contributors: Dennis and me. Quinn and Patrick did the Python part.
> CCs's predecessors are older, afaik. And 4 devs seems still "many" if
> compared to one ... ;) ...

libberylsettings was started in November 2006, still way younger than a
year ;-)
And yes, 4 devs (Quinn and Patrick weren't active at the same time, BTW)
are much more than one - but you can't blame anyone for that ;-)

Regards,

Danny