[Xcb] About next release of xcb/util

[Barton C Massey]

In message <87zl1ykfq1.fsf at keller.adm.naquadah.org> you wrote:
> 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 });

Huh.  Didn't realize that was allowed in C99--cool.  Since
it's not part of C90, you can't port it to older toolchains,
but most people don't care at this point.

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

I'd buy Ian's earlier argument that there's much less likely
to be a bug in the second version in the case of multiple
fields; the compiler remembers to reorder them for you.

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

Ian points out that maybe putting it somewhere weird is good
to encourage people to not use sync when they only need
flush.  I think there are cases where sync is needed, but
the fact that I can't name any offhand that I know for sure
is an argument on Ian's side. :-)

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

Why?

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

Maybe the wm-side icccm and ewmh bits should be split from
the client-side bits and made into their own library?
Or we could just split out the whole thing and make most
apps link against it, but that seems wrong somehow.

Anyway, it will hardly contain "almost everything".  By my
count, we'd be splitting out a minimum of five new
libraries: event, property, reply, image and renderutil.
That seems to me to be a good first cut.  We can always do
more later if we're still unhappy.

> 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
> (A la ecore/glib/whatever).

I was wrong about the event library; I thought it was
something different until I looked at it just now.  It
should definitely be split out.  The property and reply
libraries should be split out as well.  I really should have
remembered to do a git pull before I looked at stuff the
first time. :-)

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

renderutil should definitely be split out.  I think upon
reflection that image should be also.  It will continue to
depend upon some aux bits, though.  I don't think that's a
problem.

Anyway, thanks much for your careful continued review.
Hopefully we can bikeshed Arnaud real thoroughly. :-)

    Bart