<div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Compiz is desktop neutral. DavidR designed the plugin system with this<br>in mind. Compiz will work perfectly fine without the GConf plugin
<br>(which is its only tie to GNOME).</blockquote><div><br>This is basically what I found a bit questionable with upstream compiz. I kindof consider compiz something above just a new window-manager or composition-manager, I consider it the core of accelerated desktop effects. (Let's NEVER use the good ol' &quot;copy screen and blend in a fullscreen window&quot;-hack again).
<br><br>I consider the stack to be Hardware-&gt;Kernel-&gt;X-&gt;Compositor-&gt;Desktop Environment-&gt;Application.<br><br>However, it does not seem sensible to me to include a plugin in a &quot;lower&quot; layer to depend on a layer above. You see what I mean? I'm not sure the compositor should adapt to Gnome, but that Gnome should adapt to the compositor. (Just like Gnome should not adapt to applications, but vice versa.) Of course, it could be argued if the layered model shown above is actually correct/should be correct.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">gtk-window-decorator depended on gtk, but there was nothing stopping<br>someone from writing a kde window decorator that used Qt
</blockquote><div><br>Actually, I think it is, but why would we want to duplicate the effort in creating the engine, the themes etc. If you look at kde-look, and gnome-look, I'd estimate that about 80% of the themes of Kwin and Metacity are duplicates anyways.
<br></div><br></div>