On 09/05/16 07:34, Jean-Philippe André wrote:
> On 6 May 2016 at 21:09, Tom Hacohen <t...@osg.samsung.com> wrote:
>
>> On 29/04/16 05:36, Jean-Philippe André wrote:
>>> Hi Tom,
>>>
>>> On 29 April 2016 at 11:32, Jean-Philippe André <j...@videolan.org>
>> wrote:
>>>
>>>>
>>>>
>>>> On 29 April 2016 at 00:51, Tom Hacohen <t...@osg.samsung.com> wrote:
>>>>
>>>>> 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...
>>>>>
>>>>
>>>> There's a difference between eo_part and the proxy object.
>>>>
>>>> With eo_part we would use a solution like eo_super(), which I have to
>> say
>>>> is not incredibly pretty (internally: spinlock and extra bit use). I
>>>> believe that's the bit (sic) that raster didn't like much. Please
>> correct
>>>> me if I'm wrong.
>>>> Anyway, I don't think parts belong to EO outside of EFL
>>>>
>>>> The proxy object is a real EO object so you can keep it around if you
>>>> want. It's always attached to its parent.
>>>> The internal Evas Object Box (or Edje_Real_Part that really is the part)
>>>> is the owner of the proxy object.
>>>> When the proxy dies (eo_del) then a del callback will remove the entry
>> in
>>>> the owner. This way, content_get() does not return a dead object.
>>>> When the owner (Evas Box) dies, not only should it delete its children
>>>> (the proxy object), but it should also set the weak reference to NULL.
>> That
>>>> way, even if a user called eo_ref() on a proxy object, internally the
>>>> reference to the original Edje or Elm layout is reset to NULL. Calls
>> won't
>>>> work, but nothing should crash, and we can print nice error messages if
>> we
>>>> want.
>>>>
>>>> In terms of API, the advantage for both eo_part and proxy object is that
>>>> it looks like we have an object, and the API is the same for a normal
>> box
>>>> and an edje box.
>>>> The advantage of proxy object over eo_part is that it's really an EO
>>>> object. It's just not a real canvas object.
>>>>
>>>
>>> I pushed a commit testing and showing off the proxy object lifecycle:
>>> 0c2027b2af67f91dc4a203c177345e769ec07dec
>>
>>
>> The lifecycle is not that good in that commit, I spotted a few issues.
>> Take a look at my email from 11:50 UTC, I think the scheme described
>> there will solve them all.
>>
>> Just a few examples:
>>
>> table = efl_content_get(obj, "table");
>> fail_if(!table);
>> other = efl_content_get(obj, "table");
>> fail_if(other != table);
>> fail_if(eo_ref_get(other) != 1);
>>
>> That is wrong, consider the following code:
>>
>
> It is wrong, yes, I know. The code was testing the safety of the API, not
> demonstrating how it should behave exactly.
>
>
> table = efl_content_get(obj, "table");
>> a(table);
>> trouble(obj);
>> b(table);
>> eo_del(table);
>>
>> The implementation of "trouble":
>> table2 = efl_content_get(obj, "table");
>> a(table2);
>> eo_del(table2);
>>
>
> This fell outside the intended use. Or rather, this is clearly a misuse,
> just like keeping a eo_data_scope_get() pointer and messing with the eo
> object references (directly or indirectly).
>
>
> This means that the reference to table will be gone, and the proxy
>> object will be dead by the time you get to "b(table);".
>>
>>
>> As I said a few times already, with this scheme *THE PROXY OBJECT STAYS
>> ALIVE* until the object dies or you do something ugly like clear on the
>> first loop run.
>>
>
> Ok, so I'm refining the validity of the proxy object to be for a single
> call. Like you proposed earlier. Not changing the implementation yet, only
> the doc.
>
> I guess all my "safety" mechanism and explaining how it's handled has
> probably brought more confusion than anything else. Maybe my doc wasn't
> clear either, although I admit that supporting multiple function calls and
> eo_unref() was too ambitious (for the general case).
>
> I fixed the usage in the test case, but kept the explicitely bad code to
> still check for safety. It falls outside the scope of the API, though, so
> we can break it.
> I've also updated the wiki page.
>
>
> I prefer the scheme I described, but another (a bit less) acceptable
>> version would be to take the GC approach.
>> That is: don't allow the users to ref/unref/del the parts and just have
>> an idler job to do it on the next loop run. I prefer the scheme I
>> dsecribed in the other email better, but this would be acceptable too,
>> and maybe even be nicer to use.
>>
>
> Just note that we have no way to disallow eo_ref (or do we??). unref/del
> can trigger the del_callback for safety, caching or other purposes.
>
> Anyway, raster has some new ideas (temp flag & maybe lock).
> Thanks for your inputs, let's try to see if temp objects make more sense.
> I'm also not a big fan of GC.
>
>I already described a better scheme in the email I referred to previously. It solves all teh problems for both proxy and normal objects and both use cases, single and multi. All of this while maintaining properly defined lifecycle that just works. Why not that? -- Tom. ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
