[compiz] Re: Beryl Merger
mike at blueroot.co.uk
Mon Apr 2 07:34:38 PDT 2007
> Let me please enter the debate about compiz-extra. It's me who named and
> packaged the whole plugins beryl under compiz. I am not responsible of
> plugins development, I only made an aggregate work of Mike Dransfield.
> For me It was relevant to offer a packaging and a simple installation
> for the users. I took this name of compiz-extra because I thought that
> the name compiz-community or some thing similar, was too polemical, at
> the moment of its creation.
See - its all your fault ;)
Just to not upset anyone, the plugins are mostly not my work
either, I just ported them.
> My principal problem currently i don't know enough compiz development
> and I miss some time. I was not able to maintain a version for last
I have a copy of each of the current plugins working for git
That will probably be a copy of what will go into the git.compiz.org
Animation is already in git and so the version in my tarball might
be slightly out of date.
> I think, that with the recent merge between Beryl/Compiz, the tarball
> itself becomes rather problematic. The Community idea of the plugins, in
> my opinion, would be to provide the plugins one by one, thus making
> possible to the user to install a particular plugin, like themes or
> desktop applets. This way it's also possible to maintain plugins
The git.compiz.org will probably be maintained as individual plugins.
People should be able to provide an all-in-one tarball easily.
> I currently work on gnome-compiz-manager to propose a gui interface of
> binary plugins installation, one by one, like that apt or yum proposed.
> The major problem i found currently is the plugins version management
> which mainly depends on the ABI VERSION of compiz. Until a few days,
> I'll propose some concrete things.
I spoke to David a few days ago about exactly the same problem.
He agreed then to adding the plugin version as an extra member
of the vTable, but since the discussion on metadata, it might make
more sense there because it will allow for greater flexibility.
> To finish, and from what I know from the compiz-extra maintenance, I
> think that risk to maintain a compiz-extra tarball (or under its new
> name), will bring more problem, than to propose the plugins one by one.
> The problems that I saw occurring for compiz-extra, are:
> - plugins version synchronisation in each compiz-extra version
> - management of the deprecated plugins
> - selection criteria of inclusion or exclusion of one or more plugins
> - and the lack of time .....
Hopefully some clever scripts can resolve most of those problems
but I think we should go with the per-plugin idea and then see
whats possible with that.
More information about the compiz