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. -- Jean-Philippe André ------------------------------------------------------------------------------ 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
