On 03/09/2012 10:09 PM, Rafael Antognolli wrote: > 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) > Well, these don't set objects as being "part of the frame". They set the object as being THE frame.
> Evas then adds the framespace offset manually to the objects marked as > being part of the frame during evas_object_move(), No, that's incorrect. It adds the offset to objects which are NOT part of the frame: if (!obj->is_frame). 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 is only one "smart object" which is the frame. And that only occurs when using elementary for the client application. Elm will create a "frame object" which is essentially the e_border. > 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. > If we munge the framespace adjustments into the object move/geom_get functions, then we have to account for that in mouse_events which involve said object. If not, then events will not occur (or occur incorrectly). > 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. > Yes, but breaks ecore_evas applications. > 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); > Yes, they would be if done properly. You can create just an Ecore_Evas and pass the engine the "frame=" property. Ecore_Evas will then draw a "basic" frame for the window. Granted, not as fancy as the elm one, but still it will render a frame. > - 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? Yes. And still work today ;) It > seems to me that the behavior of any application using them would have > changed a lot anyway. > The whole reason for adding this stuff into Evas directly was so that applications would not have to be changed at all. > 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? Not without breaking non-elm apps and forcing people to rewrite there Ecore_Evas applications. If we remove it from Evas, then any app which uses just ecore_evas will have to be rewritten. The author(s) would have to take into account framespace manually (via the get/set functions) and manually move their objects. They would also have to do the same for handling events on any of these objects. 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) > Then how are you going to get an object (which gets moved to 0,0) to not draw under the frame ? As such, the framespace_get/set functions don't do anything related to rendering anyway. They just set some properties on the evas. The real "work" happens in object_move/geometry_get/and evas_render. dh > 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, > ------------------------------------------------------------------------------ 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
