Different engines in gtk-window-decorator

[RYX]

Another thing compiz needs (at least I think so) are different engines for the decorations. The metacity-support is nice, but it is really needed to implement it as metacity-engine and offer the possibility to create other engines - similar to emerald/cgwd. That way David could go on concentrating on the core and everyone could create new decoration-engines to get a better look&feel ... I bet zootreves would like the idea :-). The engines should maybe have the ability to handle the config-files on their own - so each engine could use its own theming-format ... that would allow using any decorator's themes with compiz (if the required engine exists).

(Though I am against such an overcomplicated packaging-system like emerald uses - simple config-files and button-images in the right folder should do the job).

Sadly I have no experience in GL-coding, otherwise I would try to implement it myself ... but we'll see ;-)

Good night, everybody!

:)

[Guest]

Yeah I agree I'd really like to see this (maybe i can bring back the zootreeves engine :) ) just as long as gtk-window-decorator doesn't become too bloated like emerald is a bit. It might be easier for someone to look at the older versions of cgwd (when engine support was first introduced) and port the plugin loader code from there, probably changing the settings system to gconf.

and it would probably need a small front-end as well to change the engine settings etc. But that could be written later on

[RYX]

Yes, its important that the decorator remains basically unchanged as far as possible. Maybe David has an idea how the engine-api could be designed best ...

[RYX]

After looking some deeper into the 5000-lines monster-code of gtk-window-decorator, I came to some more impressions:
The g-w-d-code _badly_ needs a cleanup. I think the metacity-integration using compiler-flags is messy and irritating, since various functions exist twice within the code. The decoration-engines would offer two advantages - they would reduce the lines of code in g-w-d and improve the extensibility and look&feel of the decorations. If g-w-d does not support different engines, people will most likely start creating their own decorator, porting cgwd/emerald to compiz or simply use beryl ...

But - after realizing there is no GL-based code within g-w-d, I have increasing chance to improve parts of g-w-d myself. But the engine-API would be a thing I don't really know how to implement and I think it's David's (or somone else who is more advanced in C-programming) decision, anyway. Using the engine-loader from cgwd is maybe possible, but I don't want to use it without "professional advice" ...

If someone writes to the mailing-list, maybe he can include this topic or post a link here? (I would like to see David registering and posting here, anyway ... mailing-lists are great, but not community-friendly)

:)

[mikedee]

This post is written bearing in mind that what I know about window decoration could be written on a postage stamp. I looked at the monstrosity and my brain has forbidden me from looking since :)

I agree 100% about the need to cleaning up the code and from what David has said on the list, he agrees too (gtkwd was written quickly just to demo Xgl/Compiz for some event).

I personally think that the engine idea is slightly misdirected and that maybe what is needed is another window decorator which can be designed from the ground up to support 21st century bling :).

My impression of cgwd (and emerald) is that there were lots of engines which did very similar things, they all seemed to be integrating each others features which was a lot of duplicated effort. Now it looks like they might be using heliodor more than emerald in beryl, this will mean that emerald themes will stagnate and all the theme work will be binned eventually :(

I think the best way to attack something like this would be something like this.

Seperate the code into headers and seperate related files, clean up the code so it is easy to read. Comment any nasty bits you see at the time. Some of this code might be functions which could be useful to other window decorators. This would be accepted upstream most likely and is needed before anything can be done. It would also increase your understanding of the code so that you will be better equipped to improve on it.

If common functions were seperated we could create a libwindowdecorator which could then be used by gtk window decorator. The metacity code could then be split off into a metacity window decorator. Seperating the functionality into the window decorators rather than having plugins makes sense because the user will be less confused and people can combine work into the decorator itself rather than writing plugins. If the code seperation was good then it would be as easy to write a new window decorator as it would be to write a plugin. The benefit would be that you would not be restricted in what you could do.

Try to work out exactly what people want from a window decorator. I think that a lot of cgwd themes were just metacity copies. There were some things that could be done in the engines but nothing was truly revolutionary. If we could write a list of features people want then it would be easier to know what needs to be done code wise.

I suspect what people really want is either some sort of animated wd or a OpenGL based one.

As for David contributing, I think it would be good if we could formulate a plan and then post it to the list and he can comment. I think he agrees that a forum is necessary, but he probably doesnt have the time to read through all of the posts. If we can summarise discussions he can comment where necessary.

[RYX]

Maybe you're right - the more I think of it, the more I agree that engines are not really needed. But a separation of the code will be a good start and maybe it leads to a new stand-alone decorator, independent from the metacity-decorator. Using a library used by mutliple decorators would only mean doing it the other way round - maybe there are really so many similarities that it makes sense ... I cannot say that yet (my kowledge about this fits on the same stamp - I only managed to read through the whole code and summed up what came to my mind ;-) ...).

So I'll have a look into it later (I am also slightly making progress with the transparency-engine for gtk so its hard to decide what to work on)

:)

[FunkyM]

Please don't start with "engines"...

cgwd is heavily unstructured and heck, the most efficient way to extend it is to rewrite it ;)

An old proposal (based on non-metacity cgwd and rough flyby of the source's requirements) that might help as a start for a prototype:

Current Gnome Window Decorator Components:
--------------------------------------------------------------------------------
- Window Metainformation
- Window Menu
- Draw Window: Titlebar (Icon, Caption, Buttons), Borders
- Draw Window: Switcher (Special case of above)
- Draw Window: Tooltips
- Handle/forward/hook events
- Load/Save/Hook configuration from backend

New Core Proposal: (Plugin Handler) - v0.1
--------------------------------------------------------------------------------
- Load a plugin as independent shared library
- Replace running decorators
- Window Metainformation
- Simple Plugin System
- Hook on all events (to forward to plugin if needed)
- Plugin API
* Core API
* Load/Unload Plugin (De-/Initialization)
* Configuration Storage API (Set/Get key/values, storage backend in core)
* Window Query API (Get metainformation)
* Draw Decoration API (Draw stuff "trigger"; PluginRenderDecoration()...)
* Window Decoration
* Switcher Decoration
* Tooltip Decoration
* ...
* Event API (Input, Dialogs, Buttons, "Action" Menu, Xorg, General)
* Input (Window Action Buttons)
* "Action" Menu
* Xorg
* Resize
* Tooltip (Rather fits more into deco API from my pov)
* ... (forgot anything?)

New Plugin Proposal: (Decoration Renderer) - v0.1
--------------------------------------------------------------------------------
- Plugin API based shared library
- Hook on Plugin Event API callbacks
- Render Decoration using custom backend and use Plugin API to get/set metainfo
- Draw Window: Titlebar (Icon, Caption, Buttons), Borders
- Draw Window: Switcher (Special case of above)
- Draw Window: Tooltips
- Load/Save/Hook configuration using API

Plugin Ideas: - v0.1
--------------------------------------------------------------------------------
- compiz: Simple (and old) compiz default decorations
- metacity: Metacity compatible renderer
- svg: Renderer capable to use SVGs
- ...

Only thing I am still thinking about is the configuration handling. Either the core will provide the backend and expose an API to the plugin for storage or the plugin itself will have it's own backend and the core will not have to do anything with it (might be logical, see metacity themes being controlled externally).
It all depends if "themes" should be based upon the "core" or rather on each "plugin/decoration renderer" (or a mix?).

[RYX]

That's some very nice ideas, FunkyM. After one more night reading through the code I mostly agree with them. The main goal should be to re-organize the decorator (not really re-write each line of code tough) and I also thought of a plugin-system. I think what you call "independent" is exactly what I have in mind. I'd like to offer some simple-hooks that the plugins can use to react on events or draw the decoration (or simply init themselves). A "real" plugin-API would somehow require static linking between decorator and plugin (afaik), having "one-way"-plugins would mean to only call plugin's functions from within the decorator (which I think would be enough), using the simple "dl"-function.

Having such a plugin-API in place, would offer a far better system than having the "engines" - while the plugins allow exactly the same possibilities as the engines, they can do a lot more (e.g. caring for the popup-menu, draw widgets into decoration, ...) ...

We should discuss the plugin-api a little more, but I think the general direction this aims at is pretty good.

btw: A very nice name for the new decorator could be "decoz" or "decox" - to keep familiarity with compiz ...

:)

[FunkyM]

Sorry, didn't completely read mikedee's post which has another very good point.

Looks like it's either:

libwindowdecorator (aka "libcompizdecoration" as I most likely is going to be specific in some layers?) which allows independent decorator applications to get written and access a common API to get access to the new "bling"
A unified core compiz window decorator which exposes events and methods to a plugin system which allows independent decoration backends

I guess this is just a question of normalization.

Which solution would provide the best unified core of code and thus allow for fast and efficient addition/creation of decoration renderers with various backends?

Which solution would not restrict "21st century" decorations? (OpenGL, animation, ...)

[RYX]

In my opinion (and I am not the most professional app-developer) the plugin-based system is more end-user- and developer-friendly. If we would combine both approaches, we could use a "libcompizdecoration" from within the plugins (so no need to link the plugins to the core) _and_ the decorator, while keeping one decorator-"core". I recommend looking into the decorator's code to see what could become a library-function and what could become a plugin-handler ... from my pov there are more things that can be extended to plugins (- but maybe I am just too unexperienced in creating plugin-interfaces in C-programs).

Additionally (and maybe most important) - I am really not a big fan of continuing this list with more than one entry: gnome-window-decorator, cgwd, emerald, aquamarine, heliodor, gtk-window-decorator, ... (what I mean is: the confusion about this decorator-mess is big enough - we need one unified approach that is extensible in any way and for any DE) ...

That's of course only my view of the things ...

:)

[RYX]

OK, I changed my mind a bit. I start to like the idea of multiple decorators sharing the same basic library. There are in fact a lot of universal functions that can be used by any decorator (about 2/5 of the whole file) and those should be wrapped into one library. I am unaware if (and if yes, how) this conflicts with libwnck, which is basically designed to be that, if I am not mistaken ... further I have no clue about creating a library, never did that in C (someone knows a good tutorial?).

The best way is maybe to get in touch with Quinn and other beryl-devs to design and create a libwindowdecorator used by emerald/heliodor and g-w-d ... that way we could also improve the overall compatibility between the two branches.

:)

[RYX]

Ignoring the not really overwhelming response to these ideas (but this forum is young, so I maybe just need some patience), I continued my mission to understand the 150k-monster. I split it into several logical blocks and sepearted them into multiple files and am still cleaning and dividing things.

One question: I don't know if its better to create a new decorator or work on gtk-window-decorator and I want to hear your opinions about that ...

I personally think g-w-d should continue to only support metacity (and finally drop its "legacy"-style) and the new decorator should follow the basic rules FunkM posted and (on the long run) become the official decorator (with an optional metacity-plugin for "smoothly" replacing g-w-d). Later (on the not-so-long run), the new decorator should also provide Qt-backend for being compatible with KDE.

(because I finally agree - that monster needs an organized rewrite)

I'd be happy to hear some comments ...

:)

[mikedee]

I personally feel that you should work on gwd, like you said the code really needs a tidy up and sorting out. Once this is done I think it will be easier to see what needs to be done or what can be done. I think there are some good ideas for a window decorator, once these ideas are firmed up there will hopefully be a libwindowdecorator which can be used to create your own special decorator :)

There has been a bit of talk on the lists about the heliodor decorator which was ported to compiz. You may want to look at that code to see if there is anything there that is common. The note at the top says that heliodor uses gwd code so there must be a lot that can be seperated even for totally different decorators.

[RYX]

I have really tried to organize and clean up the code of g-w-d but I came to the conclusion that a plugin-system would be the best. I have experimented with some possible approaches and think that it is best to extract the menu, the rendering and the settings-handling from the core. The plugin should also get the possibility to handle any events like mapWindow, activateWindow, closeWindow, ... and receive a (restricted) API from the core.

The libwindowdecorator is a good idea and should definetly be done in the near future and then be used by the existing and new decorators.

Does anyone know if it is a common way to compile plugins as dynamic libraries without static linking and then pass a pointer (which contains function-pointers) to their init-function to pass the whole API to the plugin? That is very simple and highly extensible. Plugins can add their own structure with function-pointers to the main API and so can use functions in other plugins. And they do not need to be statically linked to the core (which I don't know how to do). If it is somehow "ungodly" or newbie-style than please let me know ... otherwise I will try to implement it that way.

:)