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. -- Cedric BAIL ------------------------------------------------------------------------------ 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
