[Xcb] char* in structs ;)
Jamey Sharp
jamey at minilop.net
Wed Jun 15 10:24:40 PDT 2005
On Wed, 2005-06-15 at 13:08 -0400, Jeremy Kolb wrote:
> Quoting Jamey Sharp <jamey at minilop.net>:
> > On Wed, 2005-06-15 at 08:26 -0400, Jeremy Kolb wrote:
> > > Well the user can provide the display with the standard -display paramter
> > (:1,
> > > host:display ...) I'm just not sure what the functions are to make use
> > of
> > > that.
> >
> > Oh, OK. I consider that outside the scope of XCB: it won't save your
> > display string for you. You should save it yourself if you want it.
> > Also, obviously, XCB doesn't do command-line argument processing for you
> > either. :-)
>
> Right I know that, what I'm asking is... if I have the string, how do I
> generate the appropriate connection. I believe in xlib you can do dpy=
> XOpenDisplay(display_string).
>
> Or something like that, I don't have any code in front of me and I don't know
> xlib that well so I may be lying. Is this sort of thing outside of the scope
> of XCB or am I blind (very distinct possibility ;)).
Oh, gosh. OK, yes, obviously that is part of XCB's job. I completely
misunderstood your question.
The API around this is scheduled to change, though I'm not 100%
satisfied with the current plan for the new API, which is part of why
it's not there yet. (The other part is that I'm either lazy or busy,
depending on how generous you want to be.)
In the current API, you can use this code (completely untested, but I
think it's right):
char *host;
int display;
int fd;
XCBAuthInfo auth = { 0 };
XCBConnection *c;
XCBParseDisplay(display_string, &host, &display, 0);
fd = XCBOpen(host, display);
XCBGetAuthInfo(fd, &auth);
c = XCBConnect(fd, &auth);
Awful, ain't it? And I omitted error-checking for clarity:
XCBParseDisplay returns 0 on failure, XCBOpen returns -1, and XCBConnect
returns a null pointer. XCBGetAuthInfo can fail too but if it does you
can (and probably should) still try to connect.
In the currently planned API, you'll do this:
XCBConnect(display_string, 0);
This incompatible API change doesn't really seem worth doing, does it?
--Jamey
More information about the xcb
mailing list