On Mon, Sep 3, 2012 at 8:35 PM, Christopher Michael <cpmicha...@comcast.net> wrote: > 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.
Ok, my bad, I didn't look at Elm code to see how it was implemented, but this still seems to me to allow creating more objects than only one to represent 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). Yes, sorry, I wrote it wrong here, but that's what I meant to say. > > 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. I understand, but that doesn't invalidate my point. >> 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). And if we leave it as it is now, there are buggy cases. >> 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 ;) They work today, but not when they were added. > 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. Yes, old applications not written with Wayland in mind. These ones still don't need to be changed, if they are not going to be used inside wayland. >> 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. Applications that were done using lower level functions. And they don't need to be changed if they are not planned to be used inside wayland anyway. So, if you really want to make any application to still work under Wayland without changing it, how would you workaround applications that were written when there was no ecore_evas_new(), and they needed to explicitly call ecore_evas_software_x11_newI() and friends? > 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. My point is exactly to don't handle that inside Evas, just as it wasn't handled inside it at the beginning when the Wayland backend was added. If you want to make an easy transition for applications that were written without elementary, what about creating an ecore_evas_object_wayland_new, which is something similar to ecore_evas_object_image_new, that would handle that offset for you? Don't know yet if it's possible, just an idea of how to move that workaround outside of Evas... > 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, >> > -- 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
