On Mon, Jun 19, 2017 at 11:18 PM, Jean-Philippe André <j...@videolan.org> wrote: > On 20 June 2017 at 00:09, Gustavo Sverzut Barbieri <barbi...@gmail.com> > wrote: > >> On Sun, Jun 18, 2017 at 10:52 PM, Jean-Philippe André <j...@videolan.org> >> wrote: >> > On 17 June 2017 at 04:35, Gustavo Sverzut Barbieri <barbi...@gmail.com> >> > wrote: >> > >> >> On Wed, May 31, 2017 at 11:02 PM, Jean-Philippe André < >> j...@videolan.org> >> >> wrote: >> >> > Hi Dave, >> >> > >> >> > On 1 June 2017 at 08:46, Cedric BAIL <cedric.b...@free.fr> wrote: >> >> > >> >> >> On Wed, May 31, 2017 at 4:12 PM, Carsten Haitzler < >> ras...@rasterman.com >> >> > >> >> >> wrote: >> >> >> > On Wed, 31 May 2017 19:33:24 +0200 Davide Andreoli < >> >> >> d...@gurumeditation.it> >> >> >> > said: >> >> >> >> 2017-05-31 3:56 GMT+02:00 Carsten Haitzler <ras...@rasterman.com >> >: >> >> >> >> > On Tue, 30 May 2017 17:33:22 +0900 Jean-Philippe André < >> >> >> j...@videolan.org> >> >> >> >> > said: >> >> >> >> >> I have a bit of a technical question here. You may want to skip >> >> this >> >> >> if >> >> >> >> >> you're not familiar with efl_part and efl_composite_attach. >> >> >> >> >> >> >> >> >> >> I'm currently working on T5315 also known as "Refactoring >> >> >> Edje/Elm_Layout". >> >> >> >> >> The goal is to provide a uniform, simple API for both edje and >> >> >> elm_layout >> >> >> >> >> objects. >> >> >> >> >> >> >> >> >> >> Yesterday I've worked on EO API for EXTERNAL parts. Those parts >> >> are >> >> >> similar >> >> >> >> >> to swallows except that they are filled in automatically with >> >> >> widgets such >> >> >> >> >> as "elm/button" or "elm/slider". As a consequence, each >> EXTERNAL >> >> will >> >> >> >> >> support a certain, unknown, set of APIs. >> >> >> >> >> >> >> >> >> >> There is a "param_set" API that allows setting specific >> parameters >> >> >> on those >> >> >> >> >> externals, such as "label" which is the text of a button. But >> >> those >> >> >> APIs >> >> >> >> >> (currently) don't cover all the APIs supported by a widget, and >> >> >> anyway are >> >> >> >> >> limited to int/bool/double/string values (eina_value in a more >> >> >> general >> >> >> >> >> case). >> >> >> >> >> >> >> >> >> >> So a solution to exposing as much functionality as possible is >> to >> >> >> expose >> >> >> >> >> the internal widget directly. This is >> >> >> >> >> edje_object_part_external_object_get(). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> All "part" APIs in Edje.Object are meant to be implemented with >> >> >> efl_part(). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Going forward with EO API I see 3 solutions: >> >> >> >> >> #1. Do not expose the widget at all, hope that someday we can >> >> expose >> >> >> all >> >> >> >> >> useful features through generic parameter API. >> >> >> >> > >> >> >> >> > or keep external usage minimal and limited where this property >> api >> >> is >> >> >> >> > enough. >> >> >> >> > >> >> >> >> >> #2. Expose the internal widget directly (i.e. >> >> >> >> >> edje_object_part_external_object_get >> >> >> >> >> () or efl_content_get()) >> >> >> >> > >> >> >> >> > i dislike this in the general sense. for a swallow where code >> >> directly >> >> >> >> > placed and object in that swallow - getting it back ... fine. >> yes. >> >> >> anything >> >> >> >> > else i think is leaking internals... :( >> >> >> >> >> >> >> >> Why you guys are thinking of edje externals as internals objs? >> >> >> >> From the app pov is just an automatic swallow mechanism, the >> >> application >> >> >> >> MUST know the type of the widget it need to use, thus I really >> cannot >> >> >> >> see an overexposing problem here. >> >> >> >> >> >> >> >> >> > getting it requires we then always provide the object as a response >> >> now >> >> >> you >> >> >> > depend on that. this would stop us from making certain >> improvements. >> >> for >> >> >> > example: we've talked about the idea of not creating the objects >> >> inside >> >> >> an >> >> >> > edje object until actually needed (they are visible to the user). >> this >> >> >> would >> >> >> > speed up startup/creation time by reducing the work needed. and >> delete >> >> >> > invisible objects when no longer needed immediately. this would >> mean >> >> now >> >> >> you >> >> >> > get the obj - we return NULL as it doesn't exist... or we are >> forced >> >> to >> >> >> create >> >> >> > it on get (not desirable), and it means if we delete the object >> later >> >> >> when it >> >> >> > becomes invisible you may lose state you modified... the more you >> >> >> expose, the >> >> >> > less room you have to change things for the better. >> >> >> >> >> >> In this case external are like swallow. They are expected to be >> >> >> available early to the application and would have to be created as >> >> >> soon as you start. External without access to the object are >> >> >> completely useless. A button that you can't listen to a click from ? >> A >> >> >> genlist you can't populate ? If we ever pull the delayed >> construction, >> >> >> then we have to always crearte the object, like an application would >> >> >> always create them before swallowing them in edje. >> >> >> >> >> > >> >> > EXTERNAL and SWALLOW are basically the same here. >> >> > And yes, that means EXTERNAL are not exactly internal objects. >> >> > There is no good alternative to exposing the object directly to the >> user. >> >> > >> >> > As Cedric says, delaying construction may be problematic, unless >> >> > content_get() creates it and retains it as long as the edje is alive. >> >> > >> >> > BUT, here's the reasoning: >> >> > - EXTERNAL are created by Edje, and they already have an API to >> set/get >> >> > parameters (alas, not complete or powerful enough). They shouldn't be >> >> > deleted by the user. >> >> > - EXTERNAL and SWALLOW have many of their canvas properties managed by >> >> > Edje: parent, clip, geometry, visibility, color, map, ... >> >> > This is why full access to the object allows apps to change >> properties of >> >> > the object that Edje should be in charge of. >> >> > >> >> > Here's a real life example: people did swallow() followed by >> clip_set() >> >> in >> >> > order to use masks (image as clip). This used to work until I added >> >> > "clip_to" in EDC descriptions (a state change allows a mask change), >> as >> >> > edje_calc would reapply the clip (it was only set at load time before >> >> that >> >> > patch). >> >> > >> >> > We all understand here that this was a misuse of the API. It was due >> in >> >> > part to our lack of a proper documentation, but also because this was >> >> > simply possible to do. We are trying to avoid over exposing internals >> in >> >> > order to be able to optimize or add features to EFL itseSliema Marina >> >> > Hotellf without breaking apps. >> >> > >> >> > >> >> > Conclusion: >> >> > - EXTERNAL will provide direct access to the object. >> >> > - We may in the future try to prevent misuse of swallowed or external >> >> > objects. >> >> > (There's a ticket for that -- as part of T5301 -- but phab is now >> going >> >> > SPANK SPANK SPANK so can't point you to it directly.) >> >> >> >> >> >> coming late to the party, but one idea may be to implement the >> >> limitations in another way, like a per-method control where the owner >> >> object could prevent other objects or call sites to use that. >> >> >> >> practically speaking we could set a random token on an object + method >> >> and Eo would check that "on the stack" prior to method resolution. >> >> Similar to the thread domain, we could have something like this: >> >> >> >> // once, at setup >> >> efl_method_ownership_take(obj, owner, a_method); // horrible name >> :-/ >> >> >> >> // calling taken method >> >> efl_method_ownership_push(obj, owner); >> >> a_method(obj); >> >> efl_method_ownership_pop(obj); // or , owner to avoid mistakes... >> >> >> >> // to allow everytone to call that method: >> >> efl_method_ownership_release(obj, owner, a_method); >> >> >> >> Then edje would take ownership of objects, at least for methods it >> >> manages (visibility, color, clip, geometry...). >> >> >> >> I could use something like that in efl-net as well when I return the >> >> internal object for delegates... I believe other areas could benefit >> >> from that. >> >> >> > >> > See also: >> > https://phab.enlightenment.org/T5332 >> > >> > Not sure how practical the lock/unlock on every function would be. Even >> if >> > we passed an array. call_resolve would become more expensive, too (it's >> > already a high cost). But it's an idea we can keep in mind, indeed. >> >> you can know 99.9999% of time the pointer will be null and if multiple >> threads are modifying it, it's very unlikely that the pointer will be >> set. And even then, if set, the "race" condition is not important. >> >> all you need is lock when the pointer is set, so you avoid crashes. >> >> then it would look like: >> >> if (EINA_UNLIKELY(o->methods_ownership)) { >> lock(o->methods_ownership_lock); >> r = eval(o->method_ownership); >> unlock(o->methods_ownership_lock); >> if (!r) { >> ERR("method %p is owned by another entity"...); >> return; >> } >> } >> >> however, as you said on the ticket it could be restricted to eo_debug... >> <https://lists.sourceforge.net/lists/listinfo/enlightenment-devel> >> > > Well, I have to disagree on that 99.9999%. If the feature is meant to be > used by Edje then it is meant to be used a lot. Even if we limit it to > SWALLOW and EXTERNAL parts, it would still be used quite a bit (elementary > uses many swallows). Of course we can try and micro-optimize this, but this > is still a cost, used only for debugging.
remember Eo is not about just widgets anymore... thus we have main loop objects and others that could impact and would be saved by this "micro" (but simple) optimization. > Btw given the current model for threading with EO, no object can be > accessed from multiple threads (unless the bfl is locked). this is also true, could avoid the locks, or at least a lock on that... then you may share the lock with other Eo stuff that may be used during method resolution (if any). > In fact, and I just thought about it right now, Vulkan is a good example of > a new API that provides zero safety checks. a good example? Or a good bad example? :-D > What developers have to do is > to use the debug and validation libraries during their development phase > but not for production. We should probably invite our app developers to do > the same, and provide a good set of checks with eo_debug (or any similar > mechanism). 100% in agreement. -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
