On 05/12/12 11:13, Gustavo Sverzut Barbieri wrote: > On Wed, Dec 5, 2012 at 9:08 AM, Christopher Michael > <[email protected]> wrote: >> On 05/12/12 11:00, Gustavo Sverzut Barbieri wrote: >>> >>> On Wednesday, December 5, 2012, Christopher Michael wrote: >>> >>>> On 05/12/12 10:05, Michael Blumenkrantz wrote: >>>>> >>>>> there's at least one reason to keep xlib: xcb doesn't support custom >>>> >>>> mouse >>>>> >>>>> cursors. unless we add loaders and workarounds for this, it's definitely >>>>> worth keeping xlib. >>>>> >>>> >>>> Yes. XCB does not have xcursor library support (ie: there is no >>>> xcb-xcursor to read the xcursor files). We could implement some code to >>>> read those tho, and it is on my (overgrown) TODO list...just have to >>>> find time. >>> >>> >>> >>> Is that the only blocker? Seems feasible to work on that instead of >>> maintaining 2 Evas and Ecore_X engines. >>> >>> Anything else? Cedric mentioned about GL, could someone confirm? Is it >>> possible to do it in xcb and the guy uses xlib on top, if xlib is built >>> with xcb it should work. >>> >> >> Yea, GL is an issue also: >> >> "XCB-GLX only communicates with the X server, it does not perform any >> hardware initialization or touch the OpenGL client-side state. Because of >> this XCB-GLX cannot be used as a replacement for the GLX API. To use OpenGL >> in the X Windowing system, one must use the GLX API, and the GLX API is >> closely coupled with Xlib. As a result, an OpenGL application on the X >> Windows must use Xlib and thus can’t be done using only XCB." >> >> "Although writing a OpenGL application on X Windows using pure XCB is not >> possible, it is possible to use a XCB-based Xlib implementation to configure >> a rendering context in a hybrid XCB/Xlib application. Xlib is used with the >> GLX functions while XCB can be used for everything else. You do get all the >> advantages of using XCB, but you can’t get entirely rid of Xlib." >> >> Hope that clears things up a little ;) > > okay, as I expected. Then we can drop xlib and use xcb everywhere > else. It will not be as simple as just remove one #ifdef, but still > less work than maintaining 2 versions of every single ecore_x call. > > what about the xcursors? I expect it's the same, no? then we have no > work to do other than detect xcb, xlib-built-with-xcb and > xcursors-xlib.
Well, wrt xcursors, we can actually do a version for ecore_xcb that will not require the XCursor library...However, this means we will need to code which can read the xcursor file format and create cursors from that. Not "trivial" but also not difficult. Can probably do that in < 1000 lines. dh > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [email protected] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
