On Wed, 31 May 2017 19:33:24 +0200 Davide Andreoli <d...@gurumeditation.it> said:
> 2017-05-31 3:56 GMT+02:00 Carsten Haitzler <ras...@rasterman.com>: > > 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... :( > > Why you guys are thinking of edje externals as internals objs? > From the app pov is just an automatic swallow mechanism, the application > MUST know the type of the widget it need to use, thus I really cannot > see an overexposing problem here. getting it requires we then always provide the object as a response now you depend on that. this would stop us from making certain improvements. for example: we've talked about the idea of not creating the objects inside an edje object until actually needed (they are visible to the user). this would speed up startup/creation time by reducing the work needed. and delete invisible objects when no longer needed immediately. this would mean now you get the obj - we return NULL as it doesn't exist... or we are forced to create it on get (not desirable), and it means if we delete the object later when it becomes invisible you may lose state you modified... the more you expose, the less room you have to change things for the better. > >> #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 > > ------------------------------------------------------------------------------ > 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
