[Xcb] XCB naming conventions

[Bernardo Innocenti]

Ian Osgood wrote:

> One minor problem; discussing the API verbally might lead to confusion 
> with the old Xlib API.

Oh, yeah, but we'll have to deal with this problem only until there
are no more legacy applications using libX11 ;-)


>> And as we're breaking source level compatibility, I'd like to ask for
>> another change: could we re-order the fields in XCB*Event structures so
>> that it could be dispatched in a more polymorphic fashion?  The current
>> scheme requires lots of pointer casting and is very unsafe.
> 
> No, because those structures also mirror the X wire protocol, which is 
> set in stone.

Oops!  They smelled like network packets, but I wasn't sure.


> Perhaps what you would rather have is an xcb::Event base class, a tree 
> of subclasses for the specific events, and a factory for producing them 
> given an XCBGenericEvent.  Then you could have an Event::window() method 
> that really could be polymorphic, regardless of the internal structure 
> of the event on the wire.

This would add some overhead, but X events shouldn't come at such a high
rate that any application couldn't afford the extra processing.  I suppose
only drawing requests are really performance critical in X.


> (BTW, you mean e->window below, right? Only the Graphics/No exposure 
> events have drawables.)

Yeah, sorry.  I confused them because of the XCBDRAWABLE union, which
is... err... confusing.  In the previous post I was going to ask if it
could be avoided somehow, but there's probably no simple and portable
way in C (in OO languages, we'd just make XCBDRAWABLE the superclass of
both XCBWINDOW and XCBPIXMAP.


> The core XCB devs all seem to be allergic to C++.  Taking the "XCB" off 
> of every identifier and putting it in a namespace would be nice, though.

Not easy without adding an extra layer of indirection to every function
call.  As we're there, also wrapping things inside classes such as Window,
Event, and Connection wouldn't add that much overhead.

What's really missing for real world application development is some way
to bind events to user designated callbacks (or methods in OO languages).
It's the same old problem of providing context to user code (some user
structure or an instance pointer).

Maybe it's just outside of the scope of XCB, but it would help if the user
could attach a "void *userdata" into windows so that it could get it back
when needed.

Without something like this, applications and toolkits will have to
perform the extra book-keeping of mapping XID's to context structures.
I don't know much of XCB internals, but maybe XCB already has the
data structures required to do this mapping.