On 01/05/16 02:09, Carsten Haitzler wrote:
> On Sat, 30 Apr 2016 11:05:33 +0900 Jean-Philippe André <j...@videolan.org>
> said:
>
>> 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.
>
> actually i don't see the value here tbh to do this. now i have to name funcs
> so
> there is:
>
> xxxx_part_xxx
>
> so i can have:
>
> xxxx_xxx
>
> OR i have to
>
> xxxx_xxx
> vs
> xxxx_nopart_xxx
>
> just so i can drop a ", NULL" from params. given the effort to generate static
> inlines with special different names (handle the naming schemes), then have to
> deal with bindings - do they use the _part_ one or the one without? etc. etc.
> etc. ... why not just keep things simply and pass NULL if i don't care about
> part name. :) bindings of course can drop the param entirely as an optional
> parameter.
My point exactly. I think the static inline could be a nice convenience
helper that I like, and those are very easy to create (automatically
with Eolian).
------------------------------------------------------------------------------
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
