On Tue, 1 Nov 2016 10:30:08 +0100 Vincent Torri <[email protected]> said:
> On Tue, Nov 1, 2016 at 10:14 AM, Stefan Schmidt <[email protected]> > wrote: > > Hello. > > > > On 28/10/16 04:28, Carsten Haitzler (The Rasterman) wrote: > >> > >> 3. xcb was a valiant effort, but it is not even 1:1 feature for feature up > >> to date with xlib. it's off by default because of this and we need xlib > >> for gl anyway. we cant dump xlib. it's just a lot of code in our tree that > >> we likely could remove to clear out some "cruft". not to say work on xcb > >> has been bad. it's been good. it's a very very large amount of useful code > >> but it just has never proven to be any real big gains and lack of full > >> featured implementation (it's 98% there) means it kind of isn't useful. so > >> how about we drop it to simplify? > > > > It would reduce code size, code complexity, maintenance, build > > configurations, etc. Removing it gets a thumbs up from me. :) > > > > I was thinking about it before but did not ant to stomp on Devilhorns > > feet as he was still actively maintaining it. It is also a bit unclear > > to me if there are real world users out there. I would have hoped they > > would have replied by now. Maybe give them another week before the removal. > > is the removal concerning also ecore_x ? well removing the xcb back-end to ecore_x. yes. reality is if we want to do async fetches of stuff we can still do it with xcb... but get the xcb connection from xlib then write some custom xcb code for it. the problem is... x's future is far more limited now given that wayland actually has gained traction and thus investing in that future is probably not valuable. we should de-complicate our codebase and build and make it easier to trim it down and focus on where the most value lies. our makefiles and configure.ac are chock-full of options. configure.ac alone is about half the size of enlightenment 0.13 ... that's just a highly macro-ised configure script! it's a huge project of its own. in working to remove xcb i have noticed we have tonnes of options like building modules statically or not (specific modules) and we then have to maintain all the configure and maklefile goop not to mention also code support for doing this. how many people actually do this? anyway. thats a side topic. xcb is an option we do not recommend (as per this thread above), and all it does is mean every time someone works on the xlib code they have to mirror it in the xcb code. for evas sw_x11, for ecore_x etc. - removing cuts down this work. the gains from xcb have proven to not really be worth it. :/ -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
