If you want to bitch, get your b****y facts straight at least

So already two fellow devs bitched at me because I enabled the xcb plugin in xine-lib-1.1.9 by default. Enabling those by default was not a fluke, and was totally intentional. And I probably know way better than they do what the USE flag does for that package.

First, the reason why xcb is enabled by default is that the next version of Kaffeine, as well as KDE4, will require XCB support. This because it’s the only way to be able to embed a xine-lib frontend inside another application (Kaffeine inside Konqueror for instance), without having to deal with two Xlib connections. Expecting more than a couple of users wanting to check out KDE4 in the near future, I think that enabling xcb by default is a good idea; I’d rather enable xcb support in Kaffeine by default too, as without xcb, opening a video in Konqueror often leads to the browser to crash, together with all the tabs.

Second, enabling xcb in xine-lib will not break non-xcb-using frontends. Christoph wrote separate plugins, for XShm over XCB and Xv over XCB; they use a different setup than X11 plugins, so the frontends will know what they can load and what they cannot. So an XCB-based plugin (and I mean xcb, not libX11 wrapping XCB) will use the XCB plugins, and a “classic” frontend will use the libX11-based plugins. Just like fbxine (the framebuffer xine frontend) will never try to use an X11 plugin, or aaxine will never try to use the OpenGL plugin.

Third, libxine does not get any linking to libxcb directly; and as the xine plugins does not install any .la file, the libxcb dependency will not be carried around.

Fourth, even if Kaffeine had xcb enabled by default, it does not install any library that other packages link to (well beside kaffeine-mozilla-plugin, but I don’t think if that’s actually developed at all), so libxcb can’t be carried around there either.
The only way libxcb can be carried around is by enabling it in libX11.

Fifth, libxcb and libX11 has no common symbol: you can load those on the same address space without causing any collision. libxcb was designed that way.

Sixth, you can have in your system both libxcb and libX11, they don’t collide, software using libX11 won’t magically be ported to libxcb, otherwise we’d be all happy.

Seventh, you can use at the same time libX11 and libxcb applications. This is the nice thing about X11: it’s a network-oriented protocol, so as long as you use the same protocol, you can mix and match client implementations of it. You can easily run an x86 Linux application using libxcb with a SPARC Solaris X11 server as DISPLAY.

Eighth, you don’t need libX11 built as a libxcb wrapper (USE=xcb for libX11) to have xine-lib built with USE=xcb. The plugins are separated, which is the whole idea of it. You could as well have a frontend that only uses libxcb, without libX11 at all.. I was actually going to work on a similar port of xine-ui.

Ninth, you don’t even need libX11 built as a libxcb wrapper to run Kaffeine (which uses libX11 through Qt) with xcb output. libxcb was designed this way; you have two connections between the client (Kaffeine) and the X11 server, one for libX11, one for libxcb. Of course if you have libX11 built as a wrapper for libxcb, you’d get just one connection, and the code from libX11 would be disappearing. But this does not mean that a pure libX11 would break Kaffeine; it would just use more resources. On the bright side, it wouldn’t crash your Konqueror with 20 tabs open if you end up in a site that has embedded video.

And for what concerns “installing libxcb without reason”, the reason I gave you already, it’s not like I’m forcing it on anybody, the xcb USE flag can still be disabled if you don’t want to use it. It’s no more and no less as any other default USE flags. Or should I say that having the cairo USE flag enabled by default in the profile is making me install cairo without reason, as I don’t want to use it?

(And no, I don’t want cairo disabled by default; I actually have the cairo USE flag enabled in my system, and I wanted to look at cairo more deeply one day, I just wanted to take an example from some GNOME-needed technology, just because it seems to me like at least one of the two complainers might not be interested in xcb because it’s simply used by KDE applications at the moment.)

(Actually, gxine in Mercurial should also supports XCB, because, mind what, it works also better…)

P.S.: if you just say “it’s broken and I don’t want to try again”, then I’m just going to ignore you. From now on. Forever.