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

[Danny Baumann]

Hi,

> > - Offline configuration of settings
> > Classic example for this: A user turned off DBUS in his settings manager
> > which relys on DBUS ;-)
> >   
> 
> Technically this is not offline ;)

I know, but it has the same effect ;-)

> There could be other ways to configure if dbus is not enabled or
> the settings tool could have a very rudimentary way to add it.  Some
> people are claiming success by changing their initial plugins to
> dbus ini.  We should investigate that.
> 
> This is something that needs discussion.  The distro should really
> modify the default plugins list before shipping and then disallow
> the settings manager from disabling it.
> 
> You could even write a plugin which could do that sort of thing
> more easily from the inside (so long as that one was loaded ;)).

Yes, of course you are right that there might be solutions in 99% of all
cases as long as not all configuration plugins are disabled. However,
this is still not completely offline.

> > 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.
> >   
> 
> It might be harder but the end solution would be official
> and used by everyone.  Eventually someone will write this
> anyway and it will leave libbs in the cold as an unofficial
> solution.

I do not really like the official vs. unofficial separation that much
because I think people will use what will suit their needs best (or
least what they think will suit their needs best) no matter if its
official or unofficial.
What I do not really like is having to load a couple of plugins just for
configuration (in the case of ini, for example, inotify is needed in
order to be able to really work with it). This may be a matter of
personal preference, though.

> It would also be much easier to maintain because the code
> would be much smaller and would serve one purpose which
> you can isolate easily.

While I agree in principle, did you have a look at the libbs sources?
It's no voodoo and issues can be tracked down pretty easily - I did that
numerous times last week ;-)

> > - 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? ;-)
> >   
> 
> I thought these are virtually the same thing?  Its trivial
> to do with dbus/fuse and if we had a library that could
> control the existing backend plugins then we would not
> use either of those.

I don't see how this is related to dbus and fuse. Of course it can be
done with different approaches, too, but I believe that abstracting the
profile support from the actual settings manager is a good thing.

> Surely these 2 functions are among the easiest to do?
> 
> If you use the ini plugin them profile support is as easy as
> zipping up your options directory.  Dumping all current settings
> values to a file should be very very easy (no ?)

For the case of ini this is right. And for the case of gconf? ;-)

> > 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.
> >   
> 
> Again this would be excellent in another library.
> 
> So far we have
> 
> liboffline
> libprofile
> libpluginorderloading
> 
> These could all be added to a libcompizutil library but be
> distinct functions.  Your solution is an all or nothing proposition.

Libbs IS this libcompizutil ;-)
The functions are pretty distinct, and I also think we should not have a
couple of libraries which only deal with settings management. IMO (yes,
I know I'm biased) we should develop one single solution in a way so
that everyone can and wants to use it.

> There is a problem with plugin ordering in that it is not fixed
> and may be down to opinion or use as to what order to load them
> in.

Libbs provides a function which automatically sorts the plugin load
order. Of course you are free not to use this function and keep your
unsorted (or manually sorted) list.

> >> 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 recently had a look at the metadata stuff and it seems to
> answer the same problems of bcop but it is just done in a
> different way.
> 
> Metadata is official so I expect most people will use that,
> unless there is a MAJOR reason to use BCOP as well.  No,
> updating the API is not a good enough reason.

BCOP _uses_ the metadata. BCOP does not have any proprietary support,
but it just generates the option handling code _from the existing
metadata_.

> > 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". 
> >   
> 
> Are you REALLY sure about that?
> 
> It seems like thats exactly the idea at least some people have.

Yes, I am REALLY sure here. Whom are those "some people" you mean?
Perhaps they can comment on it, but I have still to hear anyone who
wants to repackage Compiz.

> Its lack of communication again leading everyone to think that
> this whatever we announce is exactly what THEY want to do (or
> causing people to misunderstand innocent requests ;)).
> 
> > 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.
> >   
> 
> Again, check the discussion on this list.  People want a new
> name for the new software.  The word distro is being thrown about
> a lot.

>From my understanding, they want _exactly_ what I outlined - an easy to
use package (or a minor number of packages) of all Compiz related
software so they don't need to dig into a couple of forum posts and
repositories to find a plugin they eventually search for. 

Regards,

Danny