On Wed, Mar 6, 2013 at 11:55 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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.
OK, any specific points or reasons why you don't like it? >> 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 > -- Rafael Antognolli http://antognolli.org/ ------------------------------------------------------------------------------ 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
