[Compcomm] Forums

[Danny Baumann]

Hi,

> > Serious question: Why would anyone seriously want to reactivate it? From
> > what I see, it combines almost all disadvantages of all settings
> > managers we had so far:
> >
> > - It's written in C.
> >   
> But would only take a tweak to get it running (if it doesnt already)
> 
> libccssettings and the plugin are both written in C so there is not much
> advantage.
> 
> Python would be a nicer choice, but that would be a good short term
> solution.

Let me clarify: It's no problem for me, but a number of people
(especially RYX ;-) ) have indicated that choosing C as language for a
settings tool is a disadvantage.

> > - It's hardcoded - you can't configure any newer plugin with it.
> >   
> It isn't, and you can

I can't try ATM because it doesn't build for me (missing header file
libxml/parser.h - any pointers which package this file belongs to?), but
the file CompizSettings-backend-functions.c looks pretty much like
hardcoded for me.

> > - Its layout looks like it's autogenerated.
> >   
> How can it be autogenerated AND hard-coded?  For your info it is
> autogenerated.  compiz-gnome-settings is hardcoded for a MUCH
> better user experience than either ccsm or compiz-settings.

I meant, it _is_ hardcoded (I will try if that assertion is valid) while
it _looks_ autogenerated. At least from screenshots I see and from my
experience when last trying it, IMO it looked no way better than ccsm.

> > - It can communicate over dbus only.
> >   
> Why is that a disadvantage?
> 
> I have explained that it is possible to have dbus running whilst
> offline, and it is possible to add a basic fallback method if dbus
> is not available (a short term solution).

I listed this item not at first position on purpose. You know my stand
on using dbus for settings managers, and I know yours ;-)

> > The only advantage of it which I see is that it works without using the
> > ccp plugin. Am I missing something?
> >   
> It works with all the standard config backends, rewriting both
> of those means the design is much more complicated than it
> needs to be and ties the GUI to the backend which is not right.
> 
> Any changes to the core config backend will not mean that
> things need to be updated every time.

I know your opinion on this, there is no need to repeat it each time ;-)

Regards,

Danny