I understand that it has problems and implications, but I still prefer to think about other solutions than the current one, before giving up and just accepting to add hacks to fix these problems.
On Mon, Sep 3, 2012 at 8:59 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Mon, 3 Sep 2012 19:09:24 -0300 Rafael Antognolli > <antogno...@profusion.mobi> > said: > > simple version. we can't do it in elm. it has to be done in evas. doing > otherwise would break basic application functionality and rendering when in > wayland which makes the wayland port/work pointless. imagine you did.. angry > birds. or space invaders. you dont use a resize object etc. etc. you manually > place image objects etc. and 0, 0 is below the titlebar.. but in wayland its > actually at the top-left of the titlebar, thus evas has to adjust for this. > >> Hello all, >> >> So, we have the current implementation of Wayland framespace inside >> Evas. It is done by setting/getting the current framespace area with: >> >> - evas_output_framespace_set (since 1.1) >> - evas_output_framespace_get (since 1.1) >> >> and by setting some objects as being part of the frame: >> >> - evas_object_is_frame_object_set (since 1.2) >> - evas_object_is_frame_object_get (since 1.2) >> >> Evas then adds the framespace offset manually to the objects marked as >> being part of the frame during evas_object_move(), and remove them >> when evas_object_geometry_get() is called. It also clips any object >> which has no clipper to the main framespace clipper, in order to avoid >> that objects are rendered over the frame area. >> >> Although I don't see any implication of the clipper solution right >> now, we were trying to solve this by adjusting the context clip when >> rendering these objects. But then we also noticed that some objects >> are children of smart objects which are part of the frame, so the code >> for this starts being more full of exceptions. >> >> There's also the problem that current solution makes the assumption >> that smart objects which are part of the frame are moving their >> children relatively to them as the default behavior, which may be >> wrong if one implements the smart move method. >> >> That's not to mention some changes that were done to the mouse events >> code to take account of the object's position. >> >> So, my point on this email is: last week Devilhorns explained about a >> solution that would move all code handling the framespace to >> Elementary, outside of Evas, that possibly fixes 90% of the current >> problems that we have now when dealing with the framespace. Add to >> that the simplification on evas render and objects code, which would >> totally avoid the need of hacks inside Evas code to support the >> framespace. >> >> Some problems raised: >> >> - old applications that didn't use Elementary: they won't be working >> nicely anyway with Wayland since there will be no frame rendered (no >> code for rendering it); >> >> - applications that have been using this >> evas_output_framespace_set/get API already for some time: did they >> really work before some months ago, when Devilhorns fixed them? It >> seems to me that the behavior of any application using them would have >> changed a lot anyway. >> >> So, what you guys thing about all of this? Would it be possible to >> move these things to Elementary only and remove them from Evas? Maybe >> making the API for framespace_set/get don't do anything related to >> rendering stuff again, just store the values and return them on get? >> (and even mark them as deprecated) >> >> IMHO, the wayland backend is still under development, its behavior has >> changed a lot between different versions of Evas since it was first >> introduced, and that would allow us to change it more. So, any other >> opinions on this? >> >> Regards, >> -- >> Rafael Antognolli >> ProFUSION embedded systems >> http://profusion.mobi >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> 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 ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
