On Mon, 2007-04-30 at 17:24 +0200, Patrick Niklaus wrote: > 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 > >
You're welcome to improve emerald, rewrite it or write a completely new decorator, I'm definitely not going to stand in the way of that. However, I suggest that you avoid duplicating work when not necessary and avoid creating alternatives to existing solutions. libdecoration contains code that is used by all decorators. If you find some code that makes sense for more than one decorator, it likely makes sense to put that code in libdecoration. What's missing in current decorators? The following is what I think is missing and how it's most properly fixed. KDE - Expose a few things in kwd that will make is possible for kwin plugins to use alpha channels and less resources. That's it, the kwin plugin API is flexible enough do do pretty much anything so I don't see a need to create an alternative here. GNOME - The existing metacity theme system is pretty limited but extending it with something like theme engines, which would allow metacity themes to look fancier when used with gwd but still work just fine when used with metacity seems like a good solution to me. Other DEs - If they don't want to use Qt or GTK, then any decorator that integrate properly with KDE or GNOME is going to be bad. Most appropriate is probably to write a new decorator for this DE but as much code as possible should be provided by libdecoration. - David _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
