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

> - 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.

Cedric BAIL

enlightenment-devel mailing list

Reply via email to