On Jun 20, 2007 11:58 PM, Vincent Torri <[EMAIL PROTECTED]> wrote: > > Hey, > > 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.
As long as the existing API operates identically, adding functions is not generally considered an API break, just an extension. That's why most version numbering systems allow minor revisions to include new functions. > What I propose: > > * ecore_x_* : if XCB is not found, Xlib code is used, otherwise, XCB code > is used. No possibility to remove roundtrips. XCB code will be only a > translation of the Xlib code. This will also remove a lot of #ifdef in > ecore_evas_x.c code > > * ecore_xcb_* : only if XCB is found. If a request needs a reply, then > one has to use a *_prefetch function to remove roundtrip. All the > informations a reply can provide will be returned by one function only. > For example, instead of having ecore_x_drawable_geometry_get and > ecore_x_drawable_border_get, we will have an > ecore_xcb_frawable_geometry_get which will return the position, size, > border and depth (all the (interesting) reply informations). This will > suppress the use of a *_fetch function. > > * the ecore_xcb_* functions will be put in another directory, with > another namespace. > > * A specific ecore_evas code will be written. > > any ideas or remarks about that plan ? While I see the development advantage of creating a new API namespace, I don't see that as the long-term future for what our X wrapper should be. The advantage we have with using ecore_x over Xlib or XCB directly is that we can provide simple representations of complex API's, and attempt to use them in the "proper" way. This reduces redundancy and potential misuse in the end user code. I would much rather see the exposed API be the ecore_x namespace, and if there is a split in "engines" that it is done in a way that doesn't expose that detail to the programmer. I believe this is the point you are getting at in your second proposal, so I'll save further comments for a reply to that. Thanks, and sorry for the ridiculously long delay. I completely forgot about this thread in the job changing/general summer turmoil. Nathan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
