[Xcb] About next release of xcb/util

[Julien Danjou]

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

> These lines don't cost anything, I think?  They're like
> three instructions in the normal case, and it's much more
> convenient than digging out the scr I had lying around and
> passing it in. :-)

They cost little, but not nothing, AFAICT. :)

>> pack_list and all other stuff after:
>>   Xlib hiding of proto stuff
>
> Rather, I would characterize this as a convenience layer on
> top of XCB to provide a more sane C interface.  Making the
> caller allocate and fill an array is just kind of
> programmer-hostile IMHO, so I tend to use these interfaces
> instead.

Hum, we never alloc'ed any array when coding awesome.

We do that:

xcb_change_window_attributes(
  connection,
  window,
  XCB_CW_EVENT_MASK,
  &(const uint32_t[]) { XCB_EVENT_MASK_SUBSTRUCTURE_REDIRECT });


Instead of doing this:

xcb_aux_change_window_attributes_checked(
    connection,
    window,
    XCB_CW_EVENT_MASK,
    &(xcb_params_cw_t) {.event_mask = XCB_EVENT_MASK_SUBSTRUCTURED_REDIRECT });

Not sure there's a *real* win… ok, you don't have to know that in array
order matters, but learning it the sooner is probably the better,
considering that you may need this for many other protocols bits.

> Certainly everybody is going to re-implement it if we don't
> provide it.  I think we could actually argue that this one
> is ubiquitous enough to just be put into core XCB.  But if
> not, then it needs to be here.

I agree too that it may belongs to XCB itself indeed.

> I think I agree, in which case I'd throw keyboard in with
> event, aux and atom also.
>
> This leads to the interesting question of whether it's
> reasonable to have several Git repos for parts of the same
> shared library.  Thoughts, anyone?

Clearly not.
So we're now talking about not splitting all xcb-util parts but building
a single .so file with almost everything inside.
Why not, anyhow you can't barely live without aux (xcb_aux_sync),
icccm and ewmh (obvious), event (at least for some magic macro) and
atom. So why not merging it in a single .so file.

event/property/reply are poor helpers that IMHO are lame. I even rewrote
them and start using event and property inside awesome, but they need
more work and there's a huge chance anyone will rewrite them. I'm sure
noone use them but awesome, because anyone doing X is enclined to
rewrite its one kind of event/reply/property/and-many-other-stuff
callback system (à la ecore/glib/whatever).

OTOH renderutil might be totally split out. And I don't know about
image, never really dived into it.

-- 
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/70e6c860/attachment.pgp>