On Thu, 28 Feb 2013 16:22:34 -0300 Rafael Antognolli <antogno...@gmail.com> said:
> tl;dr: > > To have a sub-ecore_evas inside the wayland ecore_evas. The > sub-ecore_evas would handle the client area content, while the > ecore_evas (external one) would handle the rendering of the window > decorations. not a fan of this idea. > How it should work: > ================== > > Once one asks for a wayland ecore evas (ecore_evas_wayland_shm_new, > for example), the external ecore evas would be created, with > additional space for the window decorations (here called frame). After > being created, a new ecore evas, the sub ecore evas, would be created > with its drawing contexted being smaller and having an offset relative > to the frame. The Evas of this sub ecore evas would now know about the > external area of the frame at all. > > The Ecore_Evas pointer returned by the ecore_evas_wayland_shm_new > function would be the one from the sub ecore evas, so any application > would use it without any need for special handling. There would be an > API available for returning the external/parent ecore evas of this > one, since the objects used for rendering the window decorations would > be added to this external Evas. > > Any API for resize, move, etc., of the returned ecore evas would have > to actually be applied first to the external ecore evas, and then have > the internal one adjusted. > > The external ecore evas would be always created first, with the > required surfaces allocated and so, and then the sub ecore evas would > need to have its drawing context pointed to a smaller area of this > allocated surface. > > Benefits: > ======== > > There would be no more need to keep wayland specific code for handling > the framespace inside evas render code, evas objects code, etc. > Everything would be done inside the Ecore_Evas wayland backend. > > Most problems related to this framespace code would be fixed, since > every evas object would not need to be shifted by the framespace > offset anymore, and there would be no clipper objects, etc. > > Concerns: > ======== > > I'm just worried right now if will there be any problem when handling > mouse events or if it's possible to adjust the drawing context as I > proposed above, in order to make a given Ecore_Evas to only know about > a sub-area of a given surface allocated by its parent Ecore_Evas. > > > So, do you guys have any comments, advices, know of things that > probably won't work, etc? > > Thanks for any feedback, > -- > Rafael Antognolli > http://antognolli.org/ > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > 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 ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
