[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