Talk:XCB

From Wikipedia, the free encyclopedia

Contents

[edit] Peer review of a related article

I submitted X Window core protocol for peer review, as I intend to candidate it for featured status. I would appreciate comments (Peer review page). - Liberatore(T) 18:07, 21 February 2006 (UTC)

[edit] Question

In the example, I see a function XCBWaitForEvent. As far as I understand, this function actually waits for events on the network, and this is different than the corresponding Xlib function (which looks a local queue). If this is correct, it may be a good idea to mention, as it looks like a big differnce. - Liberatore(T) 11:51, 4 May 2006 (UTC)

No, there is also an internal event queue in XCB. Both XCB and Xlib will block if the queue is empty. --IanOsgood 19:33, 24 August 2006 (UTC)
Thanks. This could be added to the article, now or in the future (Liberatore, 2006). 20:52, 24 August 2006 (UTC)

[edit] Improved version of XCB example code

This is a matter of opinion, but here is a version that is shorter and takes advantage of C99 features. I think it elucidates the task at hand much more clearly than the existing code. If there are no comments, I will change the article to include this code.

#include <xcb/xcb.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>

int main(int argc, char **argv)
{
        /* open connection with the server */
        xcb_connection_t *c = xcb_connect(NULL,NULL);
        if (xcb_connection_has_error(c))
        {
                errno = ENOTCONN;
                perror(*argv);
                return EXIT_FAILURE;
        }

        /* get the first screen */
        xcb_screen_t *s = xcb_setup_roots_iterator( xcb_get_setup(c) ).data;
        xcb_gcontext_t g = xcb_generate_id(c);
        uint32_t values[2]= {s->black_pixel, 0};
        xcb_create_gc(c, g, s->root, XCB_GC_FOREGROUND | XCB_GC_GRAPHICS_EXPOSURES , values);

        /* create window */
        xcb_window_t w = xcb_generate_id(c);
        values[0] = s->white_pixel;
        values[1] = XCB_EVENT_MASK_EXPOSURE | XCB_EVENT_MASK_KEY_PRESS;
        xcb_create_window(
                c,
                s->root_depth,
                w,
                s->root,
                10, 10, 100, 100, 1,
                XCB_WINDOW_CLASS_INPUT_OUTPUT,
                s->root_visual,
                XCB_CW_BACK_PIXEL | XCB_CW_EVENT_MASK,
                values
        );

        /* map (show) the window */
        xcb_map_window(c, w);
        xcb_flush(c);

        /* event loop */
        xcb_generic_event_t *e;
        for(
                xcb_rectangle_t r = {20,20,60,60};
                ( e = xcb_wait_for_event(c) ) &&
                        XCB_KEY_PRESS != ( e->response_type & ~0x80 );
                free(e)
        ) if(XCB_EXPOSE == (e->response_type & ~0x80))
        {
                /* draw or redraw the window */
                xcb_poly_fill_rectangle(c, w, g, 1, &r);
                xcb_flush(c);
        }
        free(e); // catch the missed free() that occurs when the for-loop exits

        /* close connection to server */
        xcb_disconnect(c);

        return EXIT_SUCCESS;
}

—Preceding unsigned comment added by 216.115.29.1 (talk • contribs) 20:10, 5 April 2007

Well? Should it be changed? --Ysangkok 16:38, 24 April 2007 (UTC)
Having never seen XCB usage before having seen this page, I would give a big fat NO to replacing it with what the anonymous editor has written.
I think the version above is much less readible. Just because C99 allows the things this anonymous editor is doing, such as mixed declarations and code, or declarations within a for(), doesn't mean that these constructs should be used at every opportunity, and it certainly doesn't make the code any clearer that the anonymous contributor has chosen to do so. This is a long function and the anonymous editor has made it much harder to read.
Also, particularly atrocious is the event loop. The anonymous editor has taken an intuitive, concise, standard-issue while/switch event loop, a very common and intuitive idiom, and butchered it into this bizarre illegible for loop followed by a horribly redundant, poorly indented series of if statements. The line of code following the loop also potentially results in freeing a null pointer (should xcb_wait_for_event ever return NULL), which will probably result in a crash for many (most?) libcs.
Seeing the article, I understand what is going on. Seeing the anonymous editor's "cleanup" is another story.
–Andyluciano 19:40, 21 August 2007 (UTC)
No, don't replace the existing code. It is additionally meant to be functionally and structurally similar to the Xlib#Example for purposes of comparison. Also, a lot of free software standardizes on C89 (ANSI C) as a lowest common denominator. --IanOsgood 21:36, 23 August 2007 (UTC)

[edit] Whats with the 0x80?

I just read this article and studied the code example carefully. Everything is well written and the example is very readable, except for the line: switch (e->response_type & ~0x80). Shouldn't there be a #define for the ~0x80 whose name conveys some concrete meaning to the corresponding bits of response_type? Or is this relying on some advanced trickery which doesn't make for a good teaching example? Thanks. Jlenthe (talk) 18:30, 10 February 2008 (UTC)