[H]omer <spam@xxxxxxx> espoused:
> Verily I say unto thee, that Linonut spake thusly:
>> * Erik Funkenbusch peremptorily fired off this memo:
>
>>> Of course I understand that, which is precisely for my question. If
>>> it's so modular, why does it need "integration"?
>>
>> Because modules need to be "integrated" with the main engine.
>>
>> So do all the plugins that can be "integrated" in.
>>
>> That's kind of the point of modularity.
>
> I'm not sure why Erik seems to have developed a mental block over this
> issue, since it really is quite simple.
>
> Compiz is not designed specifically for KDE, but rather is designed to
> be interoperable amongst different DEs (and there are /many/ for Linux).
> In order to achieve that, it requires bindings to different APIs, in
> this case KWin (which is itself modular, and capable of utilising
> different renderers, including KWin native composite, XRender and plain
> old X).
>
> The fact that each component provides different functionality does not
> mean that they work in isolation; they need to communicate. Compiz needs
> to talk to KWin to access window decoration functions specific to that
> API - hence "integration". X11 has a specific function (bitmap rendering
> and primitives), and acting as an intermediary between the composite
> renderer and the window decorator is not one of them. The specificity of
> these components is what makes GNU/Linux so modular, thus facilitating
> extremely lightweight systems if required - a concept sorely lacking in
> Microsoft Windows.
>
> If this were a simple plugin system for a browser, e.g. Firefox (XUL),
> then there'd be no need for bindings, since those plugins are written
> specifically for the XUL/XPCOM API, but the Compiz "plugin" is rather
> more than single application extension.
>
> Now certainly Compiz could be merged into KDE, but then it wouldn't be
> modular any more, would it? And Gnome would have to duplicate that
> functionality by merging the same functions. This is the path that leads
> to the kind of bloat typical on Windows ... exactly the kind of thing
> that Linux tries to avoid.
>
> Of course Compiz could be merged into X.org, next to AIGLX, which might
> make sense, except that Compiz is a window manager, and that would
> preclude other window managers like metacity (yet more loss of
> modularity and choice). Not to mention that it would unnecessarily bloat
> X.org. Also Compiz is not very useful on graphics hardware with no 3D
> support (older hardware). It also doesn't make much sense on headless
> systems running remote X or VNC, or environments using Xnest. Better by
> far to stay modular, and implement the best components for the task at hand.
>
> This really is at the heart of what GNU/Linux is all about, in the
> technical sense; extensibility through modularity, all glued together
> with bindings and wrappers. Simple, efficient and powerful.
>
> It isn't a difficult concept ... for most of us.
>
> If Erik is so interested in the specifics of Compiz KWin bindings, I
> recommend he just looks for himself, since the source is readily
> available (another benefit of GNU/Linux):
>
> http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.2.tar.gz
>
> The relevant code is in compiz-0.5.2/kde/window-decorator/
>
The particular issue he's trying to obfuscate is around integration
versus modularity. What he's failing to spot is "integration" in the
linux world is changing a module for another one which has features
suitable for the particular task in hand. The module can always be
changed back, of course. In the Microsoft world, integration is *not*
modular, whereas in the foss world, integration is modular.
--
| Mark Kent -- mark at ellandroad dot demon dot co dot uk |
| Cola faq: http://www.faqs.org/faqs/linux/advocacy/faq-and-primer/ |
| Cola trolls: http://colatrolls.blogspot.com/ |
| My (new) blog: http://www.thereisnomagic.org |
|
|
