[Xcb] EWMH API for XCB

[Josh Triplett]

On Mon, Dec 14, 2009 at 10:58:19AM -0800, Jamey Sharp wrote:
> On Mon, Dec 14, 2009 at 10:14:54AM +0100, Julien Danjou wrote:
> > At 1260732594 time_t, Jamey Sharp wrote:
> > > Do you really want it in the xcb-util bundle though? Why not manage
> > > it as its own project?
> > 
> > Not sure it's a good idea to keep things out. We [awesome] use
> > xcb-util heavily, and I spent some time last year rewriting and
> > ehancing many parts of it so it can be useful.
> > Many functions are needed for Xlib users that want to bring XCB to
> > their app/lib, and telling them to go somewhere else where upstream
> > might disapear does not seem like a valuable option right now.
> 
> I'm only complaining about all the libraries being in the same git repo.
> If you want those libraries at git://anongit.freedesktop.org/xcb/libewmh
> or similar, with issues discussed on this list and documentation and
> tarballs at xcb.freedesktop.org, that's fine with me.
> 
> I'm concerned that keeping everything together makes it harder to have
> healthy competition in library interfaces. I think X client architecture
> has stagnated over the last 20 years because when people had a problem,
> they came up with a quick fix, blessed it by putting it in Xlib, and
> then no matter how much people hated it they couldn't change it. I don't
> want to avoid quick fixes---I want to avoid blessed implementations.

I wouldn't go so far as to think of the bits in xcb-util as somehow
"blessed".  (I'd probably call them "special", with all the
meanings thereof. ;) )  Or did you have concerns about putting these
bits in the xcb directory of git repos at all?

But I second Jamey's sentiment: new code should not go in xcb-util, it
should go in its own module.  That module can most certainly live in the
xcb directory of git repositories, just in its own repository.  xcb-util
really neds splitting into one repo per library.  Having more than one
library in a single project makes things painful for many reasons,
particularly with libraries of varying usefulness, completeness, and
API/ABI stability.

- Josh Triplett