On 07/05/16 03:11, Carsten Haitzler wrote:
> On Fri, 6 May 2016 12:36:51 +0100 Tom Hacohen <t...@osg.samsung.com> said:
>
>> 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).
>
> my point was ... just de-complicate docs, api, tests, etc. by not having a
> duplicate function that just drops the param (and calls the real func with
> NULL
> as partname) ?
You don't have to test both (testing with NULL is enough) and you don't
document both, it is the same eolian function, thus it's documented once
just with a special tag saying that there is a variant or whatever.
>
> anyway.
>
> standing back a bit. out options are to either:
>
> 1. have eo_part() or whatever return a full real object
> 2. have eo_part use more bit flags in eoid OR piggyback super bit and store
> stack context info (is this a do_super? is this a do_part? is it both?) inside
> the object with locks etc.
> 3. put a partname string just about everywhere into any api that may deal with
> part names (can be optional in bindings - maybe add static inlines without
> part
> param so passing NULL can be avoided with different func name)
>
> #3 has issues with littering out api's with partname strins alongside almost
> #every object id. this will spread throughout our api a LOT
>
> #2 has issues either with losing bits in eoid or with lock/unlock, storing
> #state in objects etc.
>
> #1 has lifetime issues. we COULD define it to have a lifetime of 1 call. so
> you
> MUST do func(eo_part(obj, "blah"), ...). after this func the obj returned by
> eo_part is "consumed" by func. ie it is unref'd. if this is the definition
> then
> lifetime is known. it would be INVALID to do o = eo_part(obj, "blah") as o is
> now stored. it's not immediately consumed.
>
> while i have preferred #3 and still have reservations on #2 especially if we
> merge super and part bit info ... #1 has lifespan issues ... but if we
> strictly
> define it as above then lifespan is clear.
>
> we would have to solve the following:
>
> EVERY eo api that has an object passed in needs to know if it has to do an
> explicit unref() on it. i.e. is it a temporary object like above. how does it
> know? an extra bit in eoid? (ewwww). an eo base method used like:
>
> if (eo_tmp_get(obj)) eo_unref(obj);
>
> ? we set a tmp flag... this means that eolian should really generate this
> code
> as part of the eo method wrapper. this would solve lifetime issues.
>
> for efficiency a del intercept can be used to keep the obj alive and in some
> kind of lookup cache. if the eo obj is temporary created JUST for the purposes
> of having an api called on it and only needs to stay around for these calls,
> then we need some kind of core shared code for handling this. every obj with
> parts shouldn't have to re-implement this.
>
> the parent objects that own parts can also subclass the real objects and thus
> override all the methods someone could all and using these overrides
> intercept/block the caller from doing bad things. given a small extension like
> "lock/unlock" where the owner locks the obj when returned from a part lookup
> and unlocks it when it comes in as above ... the overridden methods simply
> block and don't do_super i the lock is in place. ... the lock/unlock method is
> private to the owning object (it doesn't expose this class outside of itself
> nor the methods) so unless you want to hack away with code generation to jump
> to the right address to do this.. it's hard to abuse. :) anyway - subclassing
> with a wrapper that can block solves "invalid access". in fact this almost
> sounds like it should be an eolian feature to be able to subclass then lock
> all
> methods (when mixin'd with a lock/block/deny and unlock/unblock/permit set of
> api's) and ONLY the methods i override will have my own implementation. so i
> end up with let's say
>
> part_find() {
> ...
> eo_tmp_set(part_obj, EINA_TRUE);
> eo_deny_set(part_obj, EINA_TRUE);
> return part_obj;
> }
>
> ... this blocks ALL api's not explicitly overridden (implemented) with an
> implementation like:
>
> eo_func_deny_wrap(obj, x, y) {
> if (eo_deny_get(obj)) {
> if (eo_tmp_get(obj)) eo_unref(obj);
> return;
> }
> eo_do_super(obj, x, y);
> if (eo_tmp_get(obj)) eo_unref(obj);
> }
>
> if i override/implement i get to write the above func myself and thus can
> permit some actions/values and store things and deny others, and on things i
> do not override - things are blanket denied when a deny is in place.
>
> anyway - i haven't fully formulated the above. it's the start of an idea. but
> it's a start of having the ability to expose just some things and deny
> the others even if the method exists and can be called.
>
>
I don't understand why complicate it, I already provided with an easier
way to deal with proxy object and the whole lifecycle issues. I'll reply
to jpeg's email again.
--
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
