2016-04-30 4:05 GMT+02:00 Jean-Philippe André <j...@videolan.org>:
> On 30 April 2016 at 02:31, Davide Andreoli <d...@gurumeditation.it> wrote:
>
> > 2016-04-28 17:51 GMT+02:00 Tom Hacohen <t...@osg.samsung.com>:
> >
> > > On 28/04/16 06:25, Jean-Philippe André 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.
> > >
> > > I also like the part API, it's essentially the same API I suggested a
> > > while back:
> > >
> > > efl_text_set(eo_part(obj, "bla"), "text"));
> > >
> > > Raster objected...
> > >
> > >
> > I tend to agree with raster, and all this eo_part seems overenginered to
> my
> > eyes.
> > I also consider the eo_part() usage ugly and not user friendly,
> > I still do not understand well what "part" is in real usage: are (for
> > example) ElmList
> > items considered parts? and table items? and swallowed object?
> >
>
> Parts are named items, so swallowed objects or actual edje parts (eg. an
> edje box or text).
>
>
> Also from the python bindings prospective this is ugly, complex to
> > implement and
> > for the user to use.
> >
> > So here is my suggestion (maybe too much simple?):
> > elf_text_set(obj, text, part @nullable)
> >
> > so no "exotic" proxy objects, refcount issues and super simple for the
> > user.
> >
>
> Yes, this is the ideal solution for bindings.
>
>
> this will be the best choice for bindings as the nullable param can be
> > omitted (at least in python) and the user can do:
> > obj.text_set("my label") or
> > obj.text_set("my second label", "part_name")
> >
> > Only drawback I can see is that in C you have to pass NULL as the second
> > param.
> >
>
> That's one drawback. A solution to it is to have static inline functions
> that are non-part variants for user convenience. It will mean two function
> names instead of just one.
>
> One technical problem though is that with eolian @property we can't have a
> key (I mean an argument in keys {} ) be at the end of the argument list.
> @optional doesn't do that.
>
This is another problem (that IMO need further discussion), "keyed
properties"
are wrong by concept, in fact the definition of Property say:
*"...Properties are read and written like fields..."*
*https://en.wikipedia.org/wiki/Property_(programming)
<https://en.wikipedia.org/wiki/Property_(programming)>*
so a prop must be used like:
obj.name = "john do"
obj.size = 100, 100
but "keyed properties" do not fit in this scenario and thus they are not
properties
at all. In fact in python bindings we do not translate *_part_name_get() to
a
"real" properties but just as 2 normal methods.
Technically they could be, probably, implemented in python (with some
hacks) like:
obj.part_text["my part"] = "my text"
but I found this ugly, hackish and welll... this is not a property!
Also I don't think other languages can do the same, I'm really curious to
see
how they are (or will be) implemented in lua or js
>
> So instead of waiting for a solution that is not there yet I decided to
> implement something that works now.
>
well... I do not consider this a valid argument :P
>
>
>
>
> >
> >
> >
> >
> > > I don't like proxy object because of the implications I described about
> > > life-cycle, and I actually wonder about the implications of your
> > > solution for bindings. I think it just won't work because the bindings
> > > won't know which functions are available (with the part API, it's just
> > > part-enabled functions on the current class).
> > >
> > > If you can convince raster, I'll happily go back to the original
> > > eo_part() solution.
> > >
> > > >
> > > > If we (or "people") really want the part APIs then I think we can
> just
> > > add
> > > > static inline / macros for C.
> > >
> > > Static inline, not macros. :) Yeah, that's the plan.
> > >
> > > >
> > > > 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?
> > > >
> > >
> > > A design issue.
> > >
> > > part = efl_content_get(obj, "bla");
> > >
> > > how do you deal with the lifecycle of part? You mentioned eo_del(), if
> > > that's the case, you can't do:
> > >
> > > efl_text_set(efl_content_get(obj, "bla"), "test");
> > >
> > > Because it would never get deleted. You can only have one or the other
> > > unless you do some ugly magic (which you don't at the moment), so there
> > > is a problem there.
> > >
> > > If it's kept alive and you don't del it at all you have a leak. If you
> > > del it implicitly under some conditions (you have an object pool of 5)
> > > it will die under the user's feet if they call it on more than 5
> > > different parts. I'm talking about the "part = " option because that's
> > > the only relevant one for lifecycle.
> > >
> > >
> > > --
> > > Tom.
> > >
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > 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
> > >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
>
>
>
> --
> 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
>
------------------------------------------------------------------------------
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
