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