[compiz] core improvements

[Kristian Høgsberg]

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