compiz - Apr 2007 - Post unification

Hello Community

Congratulations everyone for the reunification.

To kick off the process, shall we finalize channels we are going to
use for communication so that all the developers involved know what is
going on and where. Which ML and IRC would be used for 'semi-official'
communication etc.

1. Danny, Quinn and Marex have already started working on
compiz-plugins-beryl-premerge tree on http://gitweb.beryl-project.org.
The tree has a complete build system with ./autogen.sh && make
&& make
install set up.

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?

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?

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

5. In Compiz translated strings are part of gconf schemas, in beryl we
fetched the strings from the plugin and libberylsettings handled
conveying translated strings to the frontend, how will it be handled
now?

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

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

Could someone fill in the gaps and keep everyone updated.

Thanks and have a great time ahead.

-J
-- 
CyberOrg

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