compiz - Sep 2007 - core improvements

I've been making a large set of important updates to the code base
recently and there's more stuff on it's way but I'd like to get some
feedback first.

I know that some of the changes I've made and will be making require a
fair amount of work by plugin and config tool developers but I hope you
can bear with me. They are very important for the future of the project.


- API, ABI and plugin interface separation

This is in head already. compiz.h now contains an API that will be kept
fairly stable. It's useless in it's current state but more functions
will be added and simple plugins will be able to use this API and work
across multiple ABI versions. Regular symbol resolution performed by
dlopen and a simple minor version number check is enough to ensure that
a plugin is not accidentally loaded into compiz with an incompatible
API.

The ABI will likely always change rapidly and any plugin that includes
compiz-core.h is also responsible for verifying the ABI version when
being loaded.

The plugin interface can be found in compiz-plugin.h and it will rarely
change. The getCompPluginInfo symbol needs to change every time the
plugin interface changes to ensure that plugins with an old interface
aren't accidentally loaded.


- Object model

We need to easily be able to create new types of objects that plugins
can keep track of and add options to without breaking the API or even
the ABI.

The initial part of this is already in head. The object system I've
added is very simple but still sufficient. It allows us to add new core
objects without having to update any plugins.

Next step is to add an interface that will allow plugins to add their
own type of objects. This is a simple addition to the current object
system and you can expect it to land in head shortly.


- Multiple displays

Being able to manage multiple displays might seem unnecessary but making
sure that it works improves the design of the core and I'm also working
on a related project that will take advantage of it.

I've updated the core and most plugins so they work correctly with
multiple displays. However, our configuration plugins needs some more
work.


- Core object

There's now a "core" object. This is the only object that is
allowed to
be parentless, every other object needs a parent.

A lot of hooks that currently exist in the display object should be
moved into core object. All general object hooks should be in the core
object.


TODO

- Matching interface

The matching interface should be updated to work with all kinds of
objects and not only window objects. This should be easy to get done as
I had something like this in mind when I first implemented the matching
system.


- Replace the option system

This sounds like more work than what it is. All I want to do is rename
existing options to properties and add methods and signals. A property
will be pretty much exactly the same thing as an option is today except
that there's not going to be an action property. A method will be
similar to what an action option is today but it will include a
signature and the initiate/terminate bs ripped out.

What options provide today is really just a IPC mechanism. D-BUS got a
very good model for this and I'd like to adjust compiz so it matches
that model as much as possible.

So basically, each plugin can provide an interface for every object. The
interface contains a set of properties, methods and signals. E.g. a Key
or Button property is just a property that defines a key/button
combination that will trigger invocation of a specific method.

Full interface descriptions that can be used by applications to generate
bindings can easily be created from the compiz meta-data.

Further on, a plugin can be seen as a service and D-BUS could be able to
handle plugin loading and unloading as desired by applications.

The key names used by gconf plugin and group names used by kconfig
plugin needs to change to properly reflect the new object system.

gconf should use
/apps/compiz/'plugin'/'object-path'/'property'
as key name.

kconfig should use
'plugin'_'object-path'
as group name.

'object-path' could be something like this:
"display/:0/screen/0"

This will break existing configuration tools but it can't be avoided and
the should be easy to update all tools that exist.


- Output plugin support

The actual rendering should be separated from the core. Most of the
current rendering code will be moved into a GL output plugin. Multiple
output plugins can be active at the same time and they shouldn't
necessarily have to be drawing to the screen. E.g. the screenshot plugin
will be an output plugin that render to a file instead of the screen. An
xrender output plugin could easily be created. However, some of the
existing plugins will rely on the GL output plugin, e.g. blur and video
plugins.


-David

On 9/7/07, David Reveman <davidr at novell.com> wrote:
...
> - Object model
>
> We need to easily be able to create new types of objects that plugins
> can keep track of and add options to without breaking the API or even
> the ABI.
>
> The initial part of this is already in head. The object system I've
> added is very simple but still sufficient. It allows us to add new core
> objects without having to update any plugins.
>
> Next step is to add an interface that will allow plugins to add their
> own type of objects. This is a simple addition to the current object
> system and you can expect it to land in head shortly.
I browsed the patch, and it look mostly good, but I wondered why you
decided to go for a 'type' integer instead of the more custom
'class'
pointer (or objectInfo pointer).  Then you could just do

char *
compObjectName (CompObject *object)
{
 return (*nameObject->ObjectInfo) (object);
}

and the CompObjectInfo structs can be static variables in the relevant
files (screenObject info in screen.c etc) and the functions they point
to can be static too.
> TODO
>
> - Matching interface
>
> The matching interface should be updated to work with all kinds of
> objects and not only window objects. This should be easy to get done as
> I had something like this in mind when I first implemented the matching
> system.
>
>
> - Replace the option system
>
> This sounds like more work than what it is. All I want to do is rename
> existing options to properties and add methods and signals. A property
> will be pretty much exactly the same thing as an option is today except
> that there's not going to be an action property. A method will be
> similar to what an action option is today but it will include a
> signature and the initiate/terminate bs ripped out.
>
> What options provide today is really just a IPC mechanism. D-BUS got a
> very good model for this and I'd like to adjust compiz so it matches
> that model as much as possible.
Sounds cool.
> - Output plugin support
>
> The actual rendering should be separated from the core. Most of the
> current rendering code will be moved into a GL output plugin. Multiple
> output plugins can be active at the same time and they shouldn't
> necessarily have to be drawing to the screen. E.g. the screenshot plugin
> will be an output plugin that render to a file instead of the screen. An
> xrender output plugin could easily be created. However, some of the
> existing plugins will rely on the GL output plugin, e.g. blur and video
> plugins.
Interesting.  Where do you see this going?  What's the motivation for
supporting other output methods?

Kristian