On Tue, May 30, 2017 at 12:18 PM, Davide Andreoli <d...@gurumeditation.it> wrote: > 2017-05-30 10:33 GMT+02:00 Jean-Philippe André <j...@videolan.org>: >> 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.
Actually that is a good point. param_set should be only used internally by edje itself, not exposed. I guess this also make your case for #2 a better solution. Cedric ------------------------------------------------------------------------------ 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