Hi JP, On Tue, Sep 20, 2016 at 11:52 PM, Jean-Philippe André <j...@videolan.org> wrote: > On 20 September 2016 at 06:05, Cedric BAIL <cedric.b...@free.fr> wrote: >> So this email is going over what is left to be done to call EFL >> interface done. Most of this require still discussion also. Here it >> goes : >> >> - Merge Eo, Efl and Ecore >> - Make efl_uri_set/efl_file_set asynchronous >> - Convert Ecore_Exe to the new efl_io API >> - Fixup efl/interface/*.eo to all be in the correct namespace >> - Disable installation of evas/canvas/evas*.eo >> - Convert edje to become efl_canvas_layout >> - Update Edje with the new Text API >> - Convert elm_layout to become efl_ui_layout >> - Convert elm_widget to be an efl_ui_object of some sort >> - Update all efl data model to use efl_future/efl_promise >> - Add proper View and Controller for Genlist/Gengrid (see D3952 for some >> ideas) >> - There is still a large amount of .eo in elementary that are in elm >> namespace. This shouldn't be installed nor appear anywhere in the >> hierarchy. >> - Finish porting some of the widget to Efl.Ui namespace (photocam, >> index, entry, button, calendar, clock, menu, ...). This needs to be >> clarified with some pending patch in phab. >> >> This are quite a large todo list to be done with, hopefully it will... >> > > - evas smart objects > Evas smart objects are a stable legacy API but their equivalent in EO is > horrible. Efl.Canvas.Group is not an acceptable replacement in its current > form. All the methods this class defines are poorly defined overrides over > the basic object functions (show, hide, etc...). I've started some work in > this direction but it's tedious and risky. The alternative is to have no > API for custom smart objects. > > - elm_widget > elm widget was and still is an unstable / private API. I don't think > cleaning up this API is in the scope of our interfaces work, right now.
I kind of forgot about smart object and not really. Well, I was wondering if we could make elm_widget the exposed way of doing smart object with efl interface. I guess it would be indeed to big of a scope. I am fine with focusing on a simpler evas level smart object. The problem is that elm_widget is in the hierarchy of every elementary widget. So at least some binding may expose it in some way. We need a way to hide/reduce the visibility of that API at least. > - text part API > Textblock now has a new shiny eo api but edje_object and elm_layout still > define _part_text_ APIs. This needs to be transformed to Efl.Part. Yup, that was my point regarding updating edje and elm entry to use the new text API. A huge work and I have no idea of its current status. > - efl.ui.window + elm_conformant > Ideally window should have merged in the features of conformant so we avoid > this extra awkward widget. Window was supposed to handle what conformant > does. The reality is that no work towards that goal has been done yet. Oh, I missed that bit. Hum, that's problematic indeed. Need to be done. Thanks, -- Cedric BAIL ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel