On 31 May 2017 at 10:56, Carsten Haitzler <ras...@rasterman.com> wrote:
> 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. > > While I agree on the principle (hide internal objects), we must expose all the necessary features in order for externals to be useful. This includes more than just generic parameters, as we might want access to events for instance. Also all parameters would need to be auto-generated, which is not the case right now. -- 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
