2017-05-30 10:33 GMT+02:00 Jean-Philippe André <j...@videolan.org>: > Hello, > > 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).
IMO param_set should not be exposed in our public API, we already have the api of the widget itself, I really cannot see why there should be another different way to change a property of a widget... I think param_set is there just to be used internally by edje (and maybe by the externals implementation) to let the param_set in edc files works. > > 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. > #2. Expose the internal widget directly (i.e. > edje_object_part_external_object_get > () or efl_content_get()) > #3. Expose the widget API through composition, but not the widget itself. > > > Point #3 requires explanation: > efl_part(edje, "partname") returns a temporary object of a subtype of class > Efl.Canvas.Layout.Part. This object is meant to be used for a single > function call. But in this case, we can compose it with the real widget > with efl_composite_attach(). Then all the functions of the widget are > available on the part handle, except Efl.Object base functions (eg. wref, > data, events, etc...) > > > Right now I've implementewd both #2 and #3. I'm kind of happy with both, > but would like your opinions. In particular, #3 could be used as a common > pattern with efl_part() but it has the downside of overexposing internal > features. > > > Thanks in advance! > > -- > 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 ------------------------------------------------------------------------------ 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
