On 04/09/12 03:27, Rafael Antognolli wrote: > 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. > Well, in theory you can do that, but as soon as you set evas_object_is_frame_object_set, it will become the new "frame". The code is written so you can only have One. One frame to rule them all :P
>> >>> 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. > No worries :) >> >> 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. > Such as ? I have seen some of these cases myself when dealing with elementary widgets that are poorly done (or implemented incorrectly), but am curious if you are referring to anything specific here ? >>> 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. > > Even if they Are going to be used in Wayland, they would not need changes unless they were doing something engine specific. That is why this is all done at the Evas level. >>> 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. > Even if they are run inside Wayland, they won't need changes....unless they are specifically requesting the software_x11 engine (ecore_evas_software_x11 functions). Ideally, they should just use ecore_evas_new. > 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? > Yes, those would need changing (if they are specifically using software_x11_new or any of the other engine specific calls). >> 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... > How is this easier than just changing the engine specific call ? If an application uses ecore_evas_software_x11_new, then the developer can just change that to ecore_evas_new. What you are proposing here would require them to not only change the engine, but also change the code used in creating their objects. That's much more work than just changing the ecore_evas_new call. Currently, they would just need to remove the engine specific call and use the generic one. That's all the change they would need to make. If we went with the ecore_evas_object_wayland_new, then that would require them to change a lot more of their code if they wish to still run under X11 because now they need to handle object creation in X11 and wayland (each potentially done differently). dh >> 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
