On Thu, 28 Apr 2016 14:25:38 +0900 Jean-Philippe André <j...@videolan.org> wrote:
> 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.
I use Edje table, maybe box as well, but table for sure. I use it in
the embedded system that I developed for a client years ago, which
explains why no one knows I was using it. Plus that means that it's
using an ancient version of EFL, a couple of major merges ago, coz
that's when the bulk of the development was done. I don't think I use
proxy or swallows with them though. In the end, it's old code, using
an old EFL, so new changes to EFL wont make any difference to it.
So I have no opinion on this.
For my big 3D virtual world project I'm currently using Elm mostly.
Evas_3D still needs some Evas bits, but I pull them out of Elm. I have
plans for my own widget set that might happen as part of this project.
Not sure what direction that will go in eventually, but I could see my
widget set being a wrapper around either Elm or straight to Evas, with
a web page translation layer. So that the EFL UI can be used from a
web page. Waiting for some tech to mature before I experiment with
that. So again, no real opinion, not until I get around to that bit,
by which time I'll put up with what ever you have implemented in EFL.
> 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?
>
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
