[Xcb] About next release of xcb/util

[Julien Danjou]

Barton C Massey <bart at cs.pdx.edu> writes:

> Huh?  The image library uses it quite a bit. What's the win
> in reimplementing things like the visual searches?

IMHO, that's just add overhead for maybe nothing. If I take
xcb_aux_get_visualtype() (guessing it's the one your talking about), the
first lines are:

  screen = xcb_aux_get_screen (c, scr);
  if (!screen) return NULL;

Just 2 lines to do nothing because with a bit of luck I may have already
add the xcb_screen_t laying around…

Probably minor, but well.

Here's my review of the rest of aux:

- xcb_aux_get_depth:
  Is ridiculously synchronous, for god sake!
- pack_list and all other stuff after:
  Xlib hiding of proto stuff
- xcb_aux_sync:
  One-liner to send a get_input_focus(). That's hide people how X11 is
  crap. But well, that may be useful. OTOH, loading a full library just
  for a one line function is a bit overkill.
- xcb_aux_get_depth_of_visual:
- xcb_aux_get_screen:
- xcb_aux_find_visual_by_id:
- xcb_aux_find_visual_by_attrs:
  Iterators. Might be needed somehow, but again loading a full library
  just to have handy iterators to browse some struct seems to me totally
  overkill.

That makes me wonder if we should not make xcb_aux a header file of some
inlined iterator-lookup functions. :)

Note that I really do not care about what's done to xcb-aux[1], but if not
dropped it should be at least merged in a xcb-util.so library, and not
managed as it is now, i.e. in a separate .so files, as said.

I've already been hit by a GNOME guy because when adding XCB support to
libstartup-notification I add to link this last one to 3 xcb-util libs
(event, atom and aux). And they say it slows down the application startup
(no clue about that, I'm not an expert in this area).

> The
> stuff that auto-creates valueparam structs also seems like a
> win for normal use?

For people coming from Xlib, probably. I spent most time using XCB than
Xlib and I never had to use this stuff that just hides the protocol,
making people more stupid.
They are interesting for documentation purpose as I said, but to use
them, no way IMHO.

> Indeed.  The question is whether it makes more sense to
> think of it as core functionality that almost everyone will
> want, or as something that only some people will use.  I
> don't know the answer to this.

I assure you that this is something every-damn-one will use. Keyboard is
just unusable without the current 2 or 3 functions in this lib, and it
misses *a lot* of thing I really hope Arnaud will add ASAP. :-(

[1]  We barely use it in awesome.

-- 
Julien Danjou
// ᐰ <julien at danjou.info>   http://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20100323/151e737a/attachment.pgp>