Hi Dave, Cedric,
On 31 May 2017 at 05:36, Cedric BAIL <cedric.b...@free.fr> wrote: > 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. > Yes, this is a very good point. Why did I overlook this? I'll remove the extra code and unnecessary complexity I've added. As for #2 I believe it is quite necessary indeed. Despite all our efforts to avoid exposing internal widgets, in this case I can't see how to work around it :) #3 could be seen as a convenience, I'm not sure we have to remove it unless having 2 ways to do the same thing is too confusing or if composing hurts performance too much (during creation of the efl_part handle). Thanks again! -- 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
