[Xcb] Lua binding for XCB

[Barton C Massey]

In message <47321063.5000900 at hummingbird.com> you wrote:
> Barton C Massey wrote:
> > In message <4731ECFF.60501 at hummingbird.com> you wrote:

> >> As to how it goes, it seems to work surprisingly well
> >> given the amount of effort I've spent on it so far. I
> >> believe I've spent more time on my visual-id-matching
> >> algorithm than I have spent with XCB, which speaks well
> >> to the ease-of-use of XCB.

> > I also have xcb_aux_find_visual_by_id() ready to commit
> > to util/convenient/xcb_aux.c

> I suspect you misunderstand. When playing back a trace,
> the problem is "The connection block in the trace has
> these properties. Which visuals (on which screens)
> available from the server most closely resemble those in
> the trace?"

> This is a problem specific to my application, and not
> something I expect to find in any library.

Xlib has code to look for visuals with specific properties.
My XCB aux code currently does a subset of this; I'm going
to expand it to be as capable as Xlib's, though.  You can
currently match on any combination of visual attributes.

You are right, though, that this is not a similarity match,
but rather an exact match with wildcards.  Xlib's code will
return a list of visuals with the desired properties; I'm
not sure I'm going to bother returning more than
first-match.  So my code may not be as useful as Xlib's for
your case.  Presumably you just want to walk over the visual
list computing some kind of similarity score, and choose the
highest-scoring visual; you're right that neither Xlib nor
xcb_aux supports quite this level of generality, although
I'd be open to it if something generalizable could be
figured out.

At any rate, any C code I generate would be just a guideline
for you anyway, not something you could compile.  So yes,
you're kind of on your own. :-)

> Done. https://bugs.freedesktop.org/show_bug.cgi?id=13132

Thanks!

> >> ChangeProperty is not correctly implemented in luaxcb
> >> because I haven't gotten around to inverting "op". My
> >> current plan is to wait until you finish xserver-XCB
> >> and borrow that code.

> > The Python code (if that is what you mean) should be in
> > soon.

> Actually, I was referring to xcb-server (as seen on
> http://xcb.freedesktop.org/XCBToDo/ ).

I'm not understanding why server-side XCB will be helpful
for the case you describe.  Let us know what you need and
maybe we have something or can figure something out?

> >> The other minor nit is the lack of type information for
> >> the CreateWindow, ChangeWindowAttributes,
> >> Create/ChangeGC, and ConfigureWindow bit masks. This is
> >> the only place (so far) where I've had to manually set
> >> type information (XID vs integer).

> > I'm not quite following.  The masks aren't XIDs...

> No, but the data blobs that the masks refer to might be
> XIDs.

> For example, I have this line in my perl code:
> CreateWindow => [ 1, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1 ],

> Those flags refer to backround pixmap id, background
> color, border pixmap id, border color, bit gravity, ...,
> override redirect, colormap id, cursor id, just like the
> mask. Some of these things are XIDs, some of these things
> are not. libxcb just takes an array of uint32_t, and
> ignores any possible semantic meaning (xcb_pixmap_t vs
> xcb_cursor_t vs things that really are uint32_t).

> This is fine for libxcb, but it doesn't work for my
> purposes. At least, not without the above line as an
> additional hint to my code.

> This isn't something that can be fixed in XCB/proto
> without changing xcb.xsd, which I don't feel qualified to
> do.

Ah.  Right, the code that you want is in
util/convenient/xcb_aux.h, which doesn't help you at all.
I've run into similar issues, and haven't figured out quite
what the right fix is yet.  We could do something horrible
with a union, but bleah.

> It's also really low priority, since there are only a
> couple of requests that use masks. Manually maintaining
> this information is easier (in the short term) than
> writing code to parse the information out of .xml files
> modified to use a (hypothetical) new .xsd, even without
> doing the work to modify the .xsd and .xml files.

Yes. I think this is just a fundamental protocol weirdness
at the end of the day.

> Done. https://bugs.freedesktop.org/show_bug.cgi?id=13133

Thanks!

    Bart