[Xcb] ecore and xcb: looking for advices.

Vincent Torri vtorri at univ-evry.fr
Sun Mar 4 01:12:14 PST 2007


Hey,

I would like some advices on what I should do about the xcb port of ecore.

* ecore_x:

Raster wrote a wrapping of Xlib using ecore (a library similar to glib). 
You can see the api here:

http://e.kevb.net/cgi-bin/viewvc.cgi/e17/libs/ecore/src/lib/ecore_x/Ecore_X.h?revision=1.182&view=markup

it has been written before raster was aware of xcb, and it follows mainly 
Xlib api.

* ecore_xcb:

I've written an xcb port of ecore_x, and it mainly wraps xcb. Problem: its 
api is quite different from the one of ecore_x, and raster would prefer to 
keep ecore_x api. His point is: we add some functions specific to xcb (the 
methods that send the requests, and maybe some functions to get/free the 
replies). The advantage: modifying programs (mainly e17 and toolkits like 
etk or ewl) would be a minor tasks: we send all the needed requests (with 
the added methods), we use the current ecore_x methods (with the modified 
ecore_x methods, which would get the replies), and we free the replies 
with the added methods.

Simple example with current code:
    ecore_x_pointer_xy_get(win, &x1, &y1);
    atom = ecore_x_atom_get("toto");

Wanted code:
    /* added functions: we send all the needed requests */
    ecore_x_pointer_xy_get_request(win);
    ecore_x_atom_get_request("toto");

    /* existing but modified functions: we get the replies */
    ecore_x_pointer_xy_get(win, &x1, &y1);
    atom = ecore_x_atom_get("toto");

    /* added functions: we free the replies */
    ecore_x_pointer_xy_get_free(win);
    ecore_x_atom_get_free(atom);

I've not really thought about what the api could be. So the added 
functions in the example might not be correct.

I've never looked in details at Xlib/XCB, and I don't know if it can help 
me for that kind of stuff.

I already have an idea:

* ecore_x_pointer_xy_get_request and ecore_x_atom_get_request would store 
the cookie and a pointer to the corresponding reply function, in an array. 
The size of the array is not huge. Except the initialization of 
ecore_x(cb), I think that sending more than 16 requests is quite rare. If 
so, I will set the size of the array to 16. If more than 16 requests 
are sent, I will resize the array.

* ecore_x_pointer_xy_get and ecore_x_atom_get would call the reply of each 
requests in the above array. Hence some of their arguments would be 
useless. Of course, in that design, the order of the calls is important.

* the *_free functions would just be one function, actually. It would just 
free all the replies available in the array.

Is that plan a good one ? Is there a better solution ? Remark that I don't 
want to use the reply code in xcb-util, as it's not really adapted to 
ecore_x design (it would waste some memory).

thank you

Vincent

PS: nevertheless, I'll add my xcb port of ecore. It will be separate from 
ecore_x, this one having or not the xcb support described above.


More information about the Xcb mailing list