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 _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
