[Compcomm] So what's going on code-wise? Or what we're working on.

[Danny Baumann]

Hi,

> I do not disagree, I just never get answers to simple questions
> like why are you duplicating effort?
> 
> libbs is clearly duplicating effort.  I do not think anyone can
> disagree on that.

I can.
If you think libbs is just duplicating effort, please tell me how to do
the following things properly within the current Compiz core framework.

- Offline configuration of settings
Classic example for this: A user turned off DBUS in his settings manager
which relys on DBUS ;-)
The only option you have to circumvent this problem besides having libbs
is controlling the configuration backends directly - IMHO much more
invonvenient than having a library like libbs.
Besides that, you would have to duplicate all the XML parsing in the
settings tools if you hadn't a library doing it for you.

- Settings profiles
- Setting import/export
I don't see how to both of them (especially the former) properly within
the current Compiz core framework without an external library - perhaps
you can share some ideas? ;-)

Additionally, libbs already contains some nice functions to do plugin
load order automatically so you don't have to duplicate that part in
each settings manager.

> BCOP is duplication of effort, maybe opinion is split on that
> one but time will tell.

I ask again: What is it duplicating? Even after the metadata stuff is
in, there is quite a bunch of work which is avoided by BCOP (String with
restricted values handling, creation of the base, compiled-in metadata
and so on).

> I have never mentioned decorators at all because I have little
> interest in them and I do not know much about them.  I know
> RYX has done a lot of research into how to make a better
> decorator and I was simply agreeing that we should look at
> making the best rather than quickly rewriting emerald.

I think Patrick's latest post should have solved these concerns.

> I am trying to impose some stability and direction but it seems
> like creating a distribution of compiz under another name is
> much more important to you.  What other software is redistributed
> under another name and package like this?  Do not mention the
> mozilla debian thing, you know thats a totally different issue.

I'm not sure if you don't want to understand the point here. Noone wants
to repackage Compiz, but create easy-to-use packages around Compiz. I am
not sure if there is any Linux distribution that packages the kernel
under a different name than "kernel". 
I also don't think that anyone here wants to create a bunch of such
distributions - I think we just want to create that above-mentioned,
easy-to-use software around Compiz without repackaging/rebranding it.

Regards,

Danny