[Xcb] About next release of xcb/util

[Julien Danjou]

Arnaud Fontaine <arnaud at andesi.org> writes:

> * Split xcb-util bundles in several libraries.
>
>   As Alan  suggested, I  will submit  a patch to  xorg-macros to  add M4
>   macros  specific  to  XCB,  so  we  can merge  macros  in  libxcb  and
>   xcb-util. I will also prepare  another git repository for files common
>   to  all xcb-util libraries  (such as  doxygen configuration  files and
>   xcb-util-common header).
>
> * Merge  code  common  to  xcb-util/icccm  and  xcb-util/ewmh  (such  as
>   xcb_get_{atoms,windows}_reply_t) into xcb-util/property.
>
> * Fix  inconsistencies   in  xcb-util/icccm  prototypes   (for  instance
>   xcb_set_wm_protocols() should have xcb_window_t before xcb_atom_t).
>
> * Possibly use inline functions for  short functions like it has already
>   been done in xcb-util/ewmh.

You may want to start a wiki page with all that stuff.

Then you may add something I had on my mind for a while:
in xcb-property, there's a thing I can't really stand:

Function call_handler:

    if(state != XCB_PROPERTY_DELETE)
    {
        xcb_get_property_cookie_t cookie = xcb_get_any_property(c, 0, window, atom, h->long_len);
        propr = xcb_get_property_reply(c, cookie, 0);
    }
    ret = h->handler(h->data, c, state, window, atom, propr);
    free(propr);

This is really shit, because it retrieve synchronously a property, even
if you won't use it in your property-change-handler.
It even free() the property, even if you want to keep it for you usage.

Cheers,
-- 
Julien Danjou
// ᐰ <julien at danjou.info>   http://julien.danjou.info