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.) -- 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
