On Fri, 28 Oct 2016 07:30:26 -0400 Christopher Michael <cp.mich...@samsung.com> said:
> On 10/27/2016 10:28 PM, Carsten Haitzler wrote: > > so some thoughts: > > > > 1. wayland is client-side decoration land. let's not argue csd vs ssd > > (server side decorations ala traditional x11). one way or another csd is > > where things are going and there are good reasons for it being better in > > many ways. in the spirit of csd we likely will do what gnome does and use > > csd on x11 too. it can be done and thus makes wl themes/display and window > > layout and features the same as x11. ultimately this can apply to windows > > and osx too. > > > > As this is the direction that things are going anyway, I think it's a > good idea. Server side decorations conflict with wayland principles of > client-side decorations, and ultimately (imo) only serve to complicate > matters. While the theory of Server side decorations in Wayland was an > interesting one, it does not have any real traction in the other toolkit > camps (afaik) and I don't believe that any other compositor is > implementing them either, so this I agree with. i thought kwin/kde are in the "we hate CSD and will do SSD" camp? they are the only ones btw. by doing this they do complicate life though... but they will need to handle CSD clients anyway and not force frames so i guess we can plough on. in x it's a bit different as we need to advertise the shadow area so the wm can "cut that out" and not all wm's will know about this, but since gnome has been doing it and gtk3... they will need to begin to do it anyway... so i say - rely on that and also do it anyway. > > > 2. given this direction we could be even more crazy and display like > > wayland by keeping a set of pixmaps we render to and "sending" the pixmaps > > to the compositor rather than doing the std x11 composite way. only for efl > > apps but this should also fix bugs like junk content when you resize a > > window until client catches up. this borrows wl's solution for this into > > x11. the sw engine could switch easily. gl would need a little work, BUT > > with gl now we don't need buffer age for partial rendering. hooray! this > > would also help us unify api's, display paths and code paths between x11 > > and wayland too at this lower level. yes - it needs compositor support > > which means we still need the alternate path anyway... but this path could > > be more optimal... :) > > > > > 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? > > > > Given that work on xcb itself seems to have stalled (meaning I've not > seen any efforts for it to get feature parity with xlib), I would say > removing it would be the way to go. While I am partial to the xcb code > (being the one who implemented it), having it in the codebase and not > being used is just pointless, and as you've stated we still need xlib to > handle gl in there anyway so may as well just stick with xlib. ok. cool. :) > Cheers, > dh > > > thoughts? (#1 likely will happen anyway, #3 is easy and we lose nothing, #2 > > is still in the process of being through out). > > > > > ------------------------------------------------------------------------------ > The Command Line: Reinvented for Modern Developers > Did the resurgence of CLI tooling catch you by surprise? > Reconnect with the command line and become more productive. > Learn the new .NET and ASP.NET CLI. Get your free copy! > http://sdm.link/telerik > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
