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
