[Xcb] About next release of xcb/util

[Ian Osgood]

On Mar 23, 2010, at 10:01 AM, Julien Danjou wrote:

> 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.

Could be worse; xcb_sync used to be in libxcb. ;)  (I still want to see a reference that tells me where an XSync is required where an XFlush wouldn't do the job.)

> - 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).

A lot of people have dinged XCB for its many many shared libraries. I have no idea why the OS doesn't get the hate for having inefficient loaders.

Perhaps some of the smaller XCB utils could be distributed as static libraries instead?

>> 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.

I think the rationale for aux was that although some stuff hides the protocol, it also will help XCB adoption by 1) giving ex-Xlib programmers some familiar functions to call (e.g. xcb_aux_sync), 2) reduce boilerplate code that would otherwise need to be copied into every XCB project (e.g. xcb_aux_get_screen), and 3) avoid common bugs (xcb_aux_create_window, etc). For example, is the bug below immediately obvious from inspection?

  mask = XCB_CW_EVENT_MASK | XCB_CW_BACK_PIXEL;
  values[0] = XCB_EVENT_MASK_EXPOSURE | XCB_EVENT_MASK_KEY_PRESS;
  values[1] = s->white_pixel;
  xcb_create_window(c, s->root_depth, w, s->root,
                    10, 10, 100, 100, 1,
                    XCB_WINDOW_CLASS_INPUT_OUTPUT, s->root_visual,
                    mask, values)

(See XCB on Wikipedia for the proper code.)

That said, a lot of what is in aux (and util) is experimental, written before there were any XCB applications, and certainly deserves review! I agree with most of your points above. Perhaps a review of the current applications which are now using XCB is in order, looking for common patterns which can be factored out into utility libraries.  (Is http://xcb.freedesktop.org/adoption/ still up to date?)

Another thing that would really sell XCB would be an O'Reilly book.

>> 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. :-(

Amen, but it is not trivial. Search back through the mailing list for the 4 or 5 crazy things I found that XLookupString does. I think both XKB and XIM are required, not to mention a host of localized systems for testing (Japanese, for example). XLib had its fingers in a lot of pies.

Ian

> [1]  We barely use it in awesome.
> 
> -- 
> Julien Danjou
> // ᐰ <julien at danjou.info>   http://julien.danjou.info