The Road to Compiz++ Part One: Plugin-Plugins

So from now until we finally make a Compiz 0.9.0 beta release I will be doing some short blog posts on what the differences between Compiz 0.8 and Compiz 0.9 are for both users and developers. Compiz 0.9 is a complete re-thinking of Compiz 0.8. It’s like KDE4 was to KDE3. Totally new frameworks. Totally new buildsystem. Totally new API. It’s supposed to clear the ground from major architectural flaws that were in older versions of compiz to make development far easier and faster even for future version of compiz.

So without further ado, here starts the series:

Plugin Plugins (or Plugin Plugin Plugins or Plugin … Plugins)

One of the main problems with the 0.8 compiz series was that it was not easy to extend plugins and it was not easy to make library plugins. You could expose functions to other plugins from within your own plugin but it only just sort-of worked and there were all kinds of problems that needed to be overcome for it to work with a lot of unclean code that was essentially redundant, made the whole thing unstable and wasted a lot of time. It’s not quite as simple as importing some plugin as a lib then calling it’s functions, rather it had to do awkward function maps that were inserted as what looked like new plugins that other plugins then accessed with a special number then had to rely on the function map being correct and nothing moving around then had to call functions indirectly.

Compiz 0.9, with it’s object oriented design, strives to fix a lot of the problems associated with this. To understand this, we classify any plugin that works with other plugins into 2 categories:

Extension plugins

These plugins exist soley to extend the functionality of other plugins. For example, cubeaddon extends cube directly by hooking it’s functions as does scaleaddon extending scale. Animationaddon extends animation by working with animation’s internal animation manager to add new animations. It’s a one-to-one relationship between plugins.

Getting both these methods to work is complicated enough, for the former you need to handle internal functions being hooked by other plugins and for the latter you need more function maps to explain to other plugins how to add more objects to their plugins.

Compiz 0.9 has an Object Oriented design. This makes sense considering that we are working with all sorts of real things evident to the user, windows, screens, outputs, animations, plugins etc etc. It’s not like everything is a copy of a copy of a copy. This has large benefits because it means that a lot of the code to manage objects is already there and you don’t need to worry trying to tell other plugins exactly how to add objects to a queue. You just provide a base class their object derives from and that does all the work. As for the former case, there is now far more control over how functions are hooked.

Library Plugins

Library plugins are plugins that are loaded into compiz but don’t actually do anything on their own, rather they just provide functionality that other plugins can use. An example of this is the text plugin or the mousepoll plugin. The whole purpose of these library plugins is to provide functionality to other plugins that would otherwise be very similar code that is duplicated again and again. It also allows some kind of consistency.

Library plugins in Compiz 0.9 now provide real objects to other plugins rather than just function tables to manage internal variables. This means that you can take some text, render it and draw it in a few lines of code rather than having to go through a whole bunch of internal functions to make it work. The plugin only needs to be loaded for some context settings bits and pieces. Lots of functionality will be collected into library plugins for use by all plugins because they are now really easy to write. For example, we already have a compiz-toolbox plugin which performs miscellaneous functions used by a lot of the switcher plugins and both staticswitcher and switcher now use that plugin rather than duplicating lots of code. It means that any plugin now that will be similar to switcher and staticswither can just use those functions rather than having to understand any potentially confusing internal code.

The end result

  • Things are organised much better
  • Tricks that certain plugins do can be expose to other plugins rather than having to rewrite them
  • Extension interfaces are now easy to write

13 thoughts on “The Road to Compiz++ Part One: Plugin-Plugins

  1. Hiya Sam, Great to see you blogging again! I was wondering if you could mention in an upcoming blog the state of a few old issues, such as minimized windows being unmapped, so no screenshots, and also (the big one) input redirection? I understand this might be like opening up old wounds, but it always sounded as if solutions were just around the corner, and now that we’re onto Xorg-1.7 and given compiz planet’s been quiet for a bit, I wondered if there were any updates on this? Keep up the great work!

  2. That is awesome that the team is refactoring/redesigning Compiz! I love the functionality it brings as far as productivity (and of course eye-candy) but it is currently so unstable I turned it off. Being a software engineer who is proficient in C++, I’d like to help if I can to make it more robust. I’ll check out the links for contributing but if you can recommend a good place to start I’d appreciate it.

    1. @Dan, what version are you using? Do you get crashes or freezes? Do you have crash reports to help us fix those stability issues?

      1. I don’t have any crash reports because it isn’t crashing. It just doesn’t work correctly sometimes. The example that comes to mind is with Pidgin. If I’m away from my computer all day then come back to it and someone had IMed me (so that their message window popped up as a new window), the message window is just a solid gray color with no text on it. The only way to get a good Pidgin window is to close that window and open a new one, which causes me to lose whatever message(s) they sent me. Another example is when using Java Swing GUIs if you maximize the window it will fill all workspaces rather than the current workspace. Hope that info helps and sorry that’s all I’ve got.


    the thing we need most help with is porting plugins. You can start with a few simple user ones if you want.

  4. Hello.

    I don’t know if I’m asking on the right place about it, but let me go on. I would like to write a little that needs to detect when a workspace (or work area) swtich occurs. But I haven’t a clue about how/where to get started about it. Could you help me please?

    Thank you.

  5. Taiga Leather is a world leading brand name in the fashion industry. louis vuitton wallets for men A Taiga Leather is not only a sign of taste and fashion; it is also a symbol of social status and recognition. At our website the quality of handbag has reached the highest level of perfection and it comes at a very attractive price. Louis Vuitton Handbags are inspired by louis vuitton mens wallets the highly popular designs of their original counterparts.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s