[Xcb] splitting xcb/util

[Jamey Sharp]

Between this thread from March and the discussion today, I felt we
have consensus about killing the callback-based APIs, so I pushed that
commit.

I looked over the callers in awesome and i3-wm. I think in both cases,
when they quit using the event and property libraries the code will
both be clearer and faster.

Vincent's point is well-taken: If anybody wants to preserve the event,
property, or reply libraries for any reason, please go ahead and pull
them out of the git history into a new repository. If you want to host
that repository in the xcb/ directory at freedesktop.org, that can be
arranged.

Now, what's left of Arnaud's plan for releasing the utils libraries
individually?

On Fri, Mar 26, 2010 at 8:52 AM, Arnaud Fontaine <arnaud at andesi.org> wrote:
> I think  it's now  time to  sum up the  future organization  of xcb-util
> which has been discussed lately. Here it is:
>
> * xcb-util-core (only one shared library for all of them):
>  + atom
>    - Remove all the deprecated stuff (atoms now defined in xproto).
>       - Atoms.
>       - xcb_atom_get_*predefined()
>       - xcb_atom_get_fast*()
>    - Remove xcb_atom_get() which is synchronous and not really useful.
>    - Remove xcb_atom_get_name() which is synchronous and not really
>      useful, isn't it?

It sounds like you want to delete pretty much everything in the atom
library, Arnaud. If you delete the _predefined functions, then the
perfect-hashed table of predefined atoms goes. If you delete the _fast
functions, there's no async interface left there. And of course
xcb_atom_get and xcb_atom_get_name are synchronous and should die.

All that's left then are the xcb_atom_name_* functions. But as I
recall, those functions implement naming conventions from ICCCM and so
ought to be in xcb-icccm if they belong anywhere.

I always intended to implement a cache for InternAtom/GetAtomName
queries, like the one Xlib provides. xcb_atom_get_fast* was supposed
to search the predefined table first, the general cache second, and
finally issue a request if the first two missed. I still think that's
a potentially useful feature, though mostly for specialized apps like
xprop. Most toolkits and applications know at compile time what atoms
they'll need, and can refer to the predefined atom constants or, like
xcb-ewmh, can explicitly cache a known list of atoms.

I'd suggest making minimal changes here for the moment. Deleting the
deprecated "const xcb_atom_t" declarations is clearly fine by now.
Deleting xcb_atom_get is fine since you can use the async interface
instead, though xcb_atom_get_name doesn't have an async equivalent.
The rest I would be inclined to not touch yet, unless you want to
implement an atom cache and an async interface for GetAtomName.

>  + aux
>    - Julien
>  + event
>  + reply
>    - Julien

The reply library is gone, of course, but I agree: What's left of
event should be merged with aux, and probably atom, into one new
library. I think "xcb-util" would be a sensible name for the new
library, but I don't care.

> * xcb-util-wm (two shared libraries, namely icccm and ewmh):
>
>  + icccm
>    - Remove xcb_watch_* functions
>    - Rename  functions   to  xcb_icccm_OLD_NAME  (rationale:   all  the
>      libraries in xcb-util are prefixed according to their purpose, but
>      not icccm, so  I do think it's time to  change that while xcb-util
>      isn't still widely used).
>
>  + ewmh
>  + Create a  header xcb_wmh.h which contains all  the data types common
>    to icccm and ewmh.

I've removed the three xcb_watch_* functions, but the remaining
changes still should happen.

As Julien Danjou said earlier in the thread, "There's little chance
someone will use either ewmh or icccm, in 99% of the case we're rather
sure both will be used, so building 2 .so seems lame." I'd be inclined
to just merge these two libraries. I don't know what namespace the
resulting functions should be in then, though.

> * xcb-util-keysyms (one shared library)
>
>  I  do think  that it's  better to  keep this  as separate  and  not in
>  xcb-util-core because it will soon become quite big and will depend on
>  other libraries such as XKB (which should be available, hrm, soon).
>
> * xcb-util-image (one shared library)
> * xcb-util-renderutil (one shared library)

I agree that these three libraries should each stay independent.

I won't have reliable Internet access for the next three weeks, so
don't count on much feedback from me during that time. Perhaps
xcb-util will be all split up nicely by the time I get back? :-)

Jamey