On 1 June 2017 at 11:02, 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.) > Here: https://phab.enlightenment.org/T5332 -- 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
