[compiz] Re: [beryl-dev] Post unification

[Danny Baumann]

Hi,

> 2. Mikedee is keeping tarballs of individually packaged plugins, users
> would have to make && make install them individually and apply
> schemas. Are we going to use one of these methods of distribution or
> both?

My personal opinion is that a one-step setup provides a better user
experience (for those people compiling from GIT). Additionally, it's
easier to maintain in my opinion.
However, the final way of distribution (one package for all vs. one
package per plugin) should be up to the packagers.

> 3. Cornelius is working on animation plugin at git.compiz.org which is
> part of Mikedee's tarball but not of the tree at beryl-project. So how
> is development going to take place, all independent or in one place?

I believe that only an all-in-one repository for the "extra" stuff makes
sense. Otherwise it would be a pain for both developers and packagers.

> 4. Compiz core and compiz-extras tarball is using gconf schemas, while
> compiz-plugins-beryl-premerge is using bcop options for settings
> schemas.

That's not correct. BCOP by no means is meant as a replacement for GConf
schemas. BCOP XML files are just a means for storing option metadata;
and BCOP can generate both C code dealing with that options as well as
GConf schemas. In theory, BCOP could also generate all other kinds of
stuff.
BCOP is just a developer helper to get rid of annoying routine tasks
(adding an option to the code requires quite a number of steps, as an
example) and to simplify code maintenance (you don't have to change each
and every plugin whenever there is a core API change, you just have to
change BCOP).

> 6. libbs for ini, gconf and kconfig backends for settings frontends is
> in works, I am not sure of its status.

The backends are mostly done, the settings plugin is working (at least
settings can be read from it). What's missing is things like profile
support and language bindings for it (most important: Python bindings -
as far as I know Quinn is working on that).

> 7. I have a vague idea that someone is working on a settings frontend,
> not sure of the status too though.

That's a planned thing after the Python bindings are complete ;-)

Regards,

Danny