Hello, On Tue, May 30, 2017 at 1:33 AM, Jean-Philippe André <j...@videolan.org> wrote:
<snip> > 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. That would not work for function, just property, which would make this rather limited. > #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. I have my preference for #3 as I prefer hidding internal better. Still I have a concern, as for binding, the only way to use this guys is by doing a dynamic cast. So would efl_ui_something_do(efl_cast(efl_part(obj, "da_button"))) work ? > 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. In this case it is kind of ok as the theme is doing it on purpose, but it may be an issue, especially between external for legacy component and efl based one. Basically this API should only work for new eo based efl.ui object, not the old legacy one... and obviously the old legacy object should still continue to work with all the existing shortcut. -- 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
