On 27 April 2016 at 23:44, Tom Hacohen <t...@osg.samsung.com> wrote:
> On 26/04/16 06:28, Jean-Philippe André wrote:
> > Hello,
> >
> >
> > I've just merged a series of commits dealing with the box & table APIs
> for
> > Edje.Object and Elm.Layout. Since we decided not to implement anything
> like
> > eo_part at the core eo level, I've implemented part_box and part_table
> > support using fake objects.
> >
> >
> > This code:
> >> elm_layout_table_blah(ly, "part", args);
> >
> > now becomes:
> >> efl_pack_blah(efl_content_get(ly, "part"), args);
> >
> >
> > The EO returned by efl_content_get is not a real Evas Object, it's only a
> > temporary proxy object that knows about its parent (ly) and the part name
> > it refers to ("part"). It is attached to the underlying Evas Box or Table
> > created by edje, and should live
> >
> > eo_del() is legal, just call efl_content_get() again to create a new
> handle.
> > eo_ref() is not a good idea.
> >
> >
> > Note that efl_content_get() also returns real swallowed objects if the
> > "part" is a SWALLOW.
> >
> >
> > I believe text part APIs should eventually move to the same concept, once
> > the text interface is finalized (or, well, good enough). efl_text_set()
> on
> > a Layout object (or any Widget) should set the text of the "default" part
> > (whatever that means). Other parts can be accessed by efl_content_get().
> >
> >
> > Comments? Suggestions on how to improve this?
> >
> >
>
> Proxy objects were one of the original ideas to do eo_part. After that
> we decided to do the more lightweight version I proposed and after that
> it was rejected altogether.
>
> I don't like this solution because it's essentially what everyone
> (raster?) said he didn't want to do. I prefer doing the part_* versions
> (i.e double the functions), the normal versions (passing NULL as part
> name) or maybe even an eo_part.
>
The part version means we should probably have a series of part_pack
interfaces then.
Or duplicate each and every API.
Honestly, I'm not sure which solution is best. Proxy object or part APIs.
But I believe the API looks pretty decent like this.
If we (or "people") really want the part APIs then I think we can just add
static inline / macros for C.
Anyway, remember the scope of these proxy objects: Edje BOX and TABLE.
No one uses that. Proxy objects make the API behave the same as a swallowed
Box or Table.
My biggest concern with this is the "eo_del() is legal, just call ..."
> paragraph. You need to describe the lifecycle properly and not leave it
> to chance because people will use it and you need to make sure they know
> what's allowed, what's not and what they should do. For example, it's
> not obvious to me if I get a ref out if I do content_get(). If I don't I
> risk the object being deleted underneath my feet. If I do, it becomes
> more of a PITA to deal with. Which one is it?
>
You don't get a reference. The object keeps it. There is no own().
content_get() creates an object if there is not one already, eo_del() nulls
out the reference inside the object. So another content_get() triggers a
new object creation.
The proxy object can't die under your feet as it's bound to the main
object. Unless you eo_del() the container.
It's basically the same as eo_data_scope_get().
Is this a documentation issue or a design issue?
--
Jean-Philippe André
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
