[compiz] Re: Plugin Interface for Decoations

[Patrick Niklaus]

I realized some major problems with this approach. To give you a
better idea of what I'm actually talking about, take a look at this
schema:
http://media.beryl-project.org/Decoration-Schema.png

As you can see KWD, GWD and Emerald would run in the same
applications, as plugins.
This might cause problems because the main loops of Qt and Gtk are
conflicting here, which was actually one of the reasons why the
decorator was not a own plugin in compiz.

Another problem is the settings backend. To integrate into the desktop
each plugin uses its own backend. For example the emerald plugin uses
ini/gkey files + libemeraldengine but GWD gconf + metacity functions.
So basically we would end up with a complete window decorator, ported
to a plugin, which is not really what I had in mind.

An alternative would be, remaining the current structure of having
several decorator running as an own application and expand emerald to
an highly-customizeable and extentable decorator, which relies on
plugin architecture. The main goal of that decorator would be to
provide an independently theme and other rather experimental things
like animations.

This architecture is shown in this schema:
http://media.beryl-project.org/Decoration-Schema2.png

I'm not really sure which one would fit our needs best here (or if
there would be other solutions), so it would be the best if we could
discuss that here.

Regrads,
Patrick

2007/4/29, Patrick Niklaus <patrick.niklaus at googlemail.com>:
> Hi,
>
> this email is basically the result of a small discussion which made me
> think what the real end-goal of my work on Emerald-2 would be. Since
> Emerald has already a extensible system (Engines) I thought about
> giving the engines wider access, so that they are more like plugins.
> However the first thing needed is a nice plugin API. The base for that
> is the new settings backend of Emerald-2. Settings backend might not
> be the right word here, since it handles a lot more, it could also be
> called engines backend. (=> libemeraldengine)
>
> The next step is, taking GWD (which has a proper usage of
> libdecoration), port it to that system and also port most of Emerald
> features to it. This includes pixmap buttons and usage of the button
> interface for libdecoation, which will described in detail in another
> mail.
>
> Basically we would end up with a better Emerald, working name Emerald-2.
> Now, if we got that working properly we need to think about what will
> be moved to a plugin and what will stay in core. At this point we also
> need an exact definition of the plugin API. A first general definition
> can be found below.
>
> It would be really nice if I could get some feedback or suggestions on my plans.
>
> BTW. Please do not start a flame war because of the working name, it
> will be probably changed and I don't want to decide about it yet, but
> since it shares most of its features I choose this name for now.
>
> ==== The Plugin Interface ====
>
> * Settings:
>   - make use of libemeraldengien settings backend
>     => could cause problems because Metacity and KDE have different backends
>   - maybe extent it so it would better fit our needs
>   - but keep in mind that we won't need a second implementation of the
> compiz options system
>
> * Event handling:
>   - provide notifies for plugins for some specific events
>   - not sure which one will be needed
>   - however resize/move/enter/leave will probably be included
>
> * Integration into Emerald-2:
>   - standard button drawing will be probably handled by plugins
>   - window title drawing probably too
>   - we need a system so plugins can sign up for providing functions
>     => wrapping stack like in compiz
>     => slot system, so only one plugin at the same time can sign up for it
>
> * Integration into DE's:
>   - add a plugin for Metacity support
>   - maybe port the KDE decoration also to a plugin (if thats possible)
>
> Regards,
> Patrick
>