On Tue, 30 May 2017 17:33:22 +0900 Jean-Philippe André <j...@videolan.org> said:
> 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. or keep external usage minimal and limited where this property api is enough. > #2. Expose the internal widget directly (i.e. > edje_object_part_external_object_get > () or efl_content_get()) i dislike this in the general sense. for a swallow where code directly placed and object in that swallow - getting it back ... fine. yes. anything else i think is leaking internals... :( > #3. Expose the widget API through composition, but not the widget itself. while this makes sense... i dislike it too because like #2... exposing... :( > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
