2012/9/6 Christopher Michael <[email protected]>: > On 06/09/2012 07:54 PM, Iván Briano wrote: >> >> 2012/9/6 Christopher Michael <[email protected]>: >>> >>> On 06/09/2012 05:25 PM, Rafael Antognolli wrote: >>>> >>>> Hey, >>>> >>>> On Thu, Sep 6, 2012 at 1:03 PM, Christopher Michael >>>> <[email protected]> wrote: >>>>> >>>>> Ok, so I modified the evas_object_move and evas_object_geometry_get >>>>> functions to work with all evas objects now (not just smart objects, >>>>> but >>>>> rectangles, etc, etc). Every example in ecore_evas/src/examples works >>>>> well now without modification ... with ONE exception. (elm breakage >>>>> because of this is another story that I have not really dug into yet) >>>>> >>>>> That exception is this: >>>>> >>>>> Since evas_object_move handles adding the framespace to the object >>>>> (geometry_get will subtract it), the examples do not work without an >>>>> evas_object_move first. Here is a bit of example code (taken from >>>>> ecore_evas_basics_example.c): >>>>> >>>>> bg = evas_object_rectangle_add(canvas); >>>>> evas_object_color_set(bg, 0, 0, 255, 255); >>>>> evas_object_resize(bg, 200, 200); >>>>> evas_object_show(bg); >>>>> ecore_evas_object_associate(ee, bg, >>>>> ECORE_EVAS_OBJECT_ASSOCIATE_BASE); >>>>> >>>>> This will fail (in that bg will not be in the proper position) because >>>>> evas_object_move is not called for it (to adjust position for >>>>> framespace). Sadly, I am seeing a lot of this in the examples >>>>> (evas_object_move not being called)...which means it is probably being >>>>> done the same way in various code all over the place. >>>>> >>>>> There are two ways to handle this (as I see it). One, we can add the >>>>> evas_object_move to the examples and require that people call >>>>> evas_object_move after object creation in their code). Not an ideal >>>>> solution imo :/ >>>>> >>>>> The other thing we could do is, in evas_object_add (or somewhere >>>>> appropriate), add the framespace adjustments during object creation. >>>>> This approach seems more viable imo. If we add it there, there is no >>>>> problem with evas_object_move because it already checks if the object >>>>> is >>>>> in framespace or not. Since the framespace adjustments would be made at >>>>> creation, then evas_object_move will see that it's not in framespace >>>>> and >>>>> thus not Re-add the framespace values. >>>>> >>>>> I am sure that both of these approaches have additional >>>>> drawbacks...thus >>>>> this RFC email before I go any further. >>>> >>>> >>>> I discussed with several people here and we all prefer the second >>>> approach, add the offset upon object creation. >>>> >>>> However, there's also an additional problem: what happens if the >>>> framespace size changes? Let's say that the user sets an option on the >>>> application window to become borderless, or don't have title bar. In >>>> such case, the framespace would change, breaking everything until the >>>> next evas_object_move for each object, right? >>>> >>> >>> In theory, yes it would break things until the next move, however under >>> the wayland engines, when you toggle borderless then essentially what we >>> are doing is deleting the frame (and recreate when border is set to true >>> again), so .. when the frame gets deleted then the window will be >>> resized ( to adjust the evas_viewport ) which will trigger updates to >>> the objects (position, etc). >>> >> >> Does this really happen? > > Haven't been to the office to test it yet. > > > Isn't this real only for Elementary apps that are >> >> likely to get all their resize callbacks triggered? > > > Not really. You can do resize callbacks on non-elm stuff ;) (pretty basic > evas stuff there) ;) but yes, will also affect elm apps. >
I meant that only Elementary would handle it on its own, anywhere else users would have to do it manually. Also, resizing the viewport won't just trigger normal Evas callbacks, as objects will not have changed their size or position. > > The case of manual placement >> >> of objects may still be a problem. >> >>> I'll run some tests tomorrow to verify that this won't be a problem, but >>> I suspect that this will be a non-issue (as I already have fullscreen >>> implemented which does the same thing essentially as the borderless will >>> do, and I don't see the problem there), but good point :) >>> >> >> I don't know how much of a possibility it is, but what about a frame >> changing >> size instead of just going away? > > > Well, we could raise an event or something to inform apps that it has > happened ... tho really, in wayland, apps (clients) are supposed to draw > their own frames. We do it in efl because we're nice (or something...) > Speak for yourself, I do not intend to be nice. > > Though it's probably the same case. >> >> Is it worth it to just forget about it and leave applications fix >> themselves and blame >> the unusual cases on their unusualness? > > > If efl apps were to draw their own frames, then I would say sure leave it to > them, but that is not the case w/ efl apps. Ecore_Evas has code to draw a > very very basic frame (if none is provided) as a fallback. And elm apps have > a more "full featured" frame (aka the e_border look). > > > Since we are already fixing position all >> >> over the place, what about checking the difference when setting a new >> framespace >> and go through the object list updating them? >> > That's a possibility ... and actually the same approach I was considering > for this problem...but was going to bring that up in a different RFC. (don't > want to hijack this thread wrt a different problem). > Then I guess we are done. Back to drink coffee and look busy. > dh > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
