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

Reply via email to