2017-05-30 10:33 GMT+02:00 Jean-Philippe André <j...@videolan.org>: > 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. >
First of all: I'm a fan and a big user of the external parts in edje, I use them everywhere I can (fe my mediacenter themes are heavily based on externals). I think externals are a key-feature if you want your application to be really themable: think, for example, at a gui designer app! the designer is able to fully design the GUI in the designer (instead of putting lots of empty swallow, that do not size correctly and therefore make the gui inside the designer app complete different from the final result) Having said that, I'm totally for the solution #2: just provide a single, simple, and clear function that return the real widget, with a clear notice in the docs that say to not use any unwanted function on the returned obj. The #3 seems to me really over-enginered, complex and difficult to learn. So, for the KISS and the OnlyOneClearWayToDoIt principles I vote to keep #2 and wipe #3 > > Point #3 requires explanation: Simply the fact the #3 "require explanation" is a point in favor of the theory that it is too much complex :) > 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...) No data_* and no events in the returned external part is another big fail of #3 .... and, really, if no events means you cannot attach any events cb to your external part, this option is totally un-usefull: I never used a single widget in my life without attaching an event to it. > > > 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 ------------------------------------------------------------------------------ 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
