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). 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
