[Xcb] About next release of xcb/util

[Vincent Torri]

On Tue, 23 Mar 2010, Ian Osgood wrote:

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

there are some in the xcb evas engine. Ask raster for more informations

Vincent

>> - 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
>
>
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
>
>