Hey
On Thu, 21 Jun 2007, Vincent Torri wrote:
> Here is a suggestion of a new ecore_xcb api, according to all the remarks I
> have noted.
>
> Currently:
>
> * ecore_x_* functions use Xlib code if XCB is not found, otherwise use XCB
> code. In the latter case, one has to use 2 other functions (*_prefetch and
> *_fetch functions) to remove roundtrips, in case an X request needs a reply.
> Even if I only added functions, it can be considered as an API break.
Proposal #2:
If XCB is found:
* If a request does not need a reply, the function is just a translation
of the Xlib code. Nothing much to say.
* If a request needs a reply, there will be 2 implementations:
- a function with the same name than the Xlib code, which is a
translation of the Xlib code. No possibility to remove round trips. This
is in order to keep current code working when XCB is found.
- 2 functions, one that sends the request, the other one that get the
reply. For example, let's take the GetGeometry request:
ecore_x_drawable_geometry_get_prefetch : will just call
xcb_get_geometry_unchecked and will cache the cookie, like the current
implementation. That function is non blocking.
ecore_x_drawable_geometry_get_async : will ask for the reply by calling
xcb_get_geometry_reply. As raster wants an event driven api, that function
can have that prototype (idea from rephorm, if I'm not mistaken):
void ecore_x_drawable_geometry_get_async(Ecore_X_Drawable drawable (unused),
void (*reply_cb) (void *reply, void
*data),
void *data)
Some remarks:
* the async prefix is added to avoid having the same name than a current
Xlib function.
* with the current implementation of the cache of the cookies, the _async
functions must be called in the same order that the _prefetch functions. I
guess that it must be changed.
* I don't really know if the 'drawable' parameter is needed. I mean, it's
unused with the current implementation of the cache, but can be needed if
we want to the _async functions to be called in any order.
* when xcb_get_geometry_reply has returned, the callback 'reply_cb' is
called with a pointer to a structure containing all the data the reply
provides. With that example:
struct Ecore_X_Geometry
{
int x;
int y;
int width;
int height;
int border;
int depth;
}
* that function is blocking (as xcb_get_geometry_reply is)
Another possibility (raster's idea) for
ecore_x_drawable_geometry_get_async is to sent an event
ECORE_X_REPLY_GEOMETRY_GET just when the xcb_get_geometry_reply call has
returned. The event would contain (actually, would be) the structure
above. Then, the prototype would just be:
void ecore_x_drawable_geometry_get_async(Ecore_X_Drawable drawable (unused))
raster: in that case, should we also add those events in the Xlib
implementation ?
Any ideas or comments are welcome.
Vincent
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
