Hello. On 13/06/16 20:48, Cedric BAIL wrote: > Hello, > > On Mon, Jun 13, 2016 at 7:01 AM, Stefan Schmidt <ste...@osg.samsung.com> > wrote: >> On 13/06/16 14:18, Stefan Schmidt wrote: >>> On 13/06/16 13:16, Tom Hacohen wrote: >>>> As part of the development process of the new Eo API we marked all of >>>> the API all around as beta. We mainly use EFL_EO_API_SUPPORT, but I >>>> think we maybe also use EFL_BETA_API_SUPPORT, need to verify that. >>>> >>>> Anyhow, now is time to remove these tags (where appropriate), so these >>>> APIs are released. >>>> >>>> I guess we can just remove all of the occurrences of the EO one, but we >>>> need to be more careful with the other one. >>>> >>>> Is there anyone who has time to take care of this? Stefan? Or should I >>>> try to tackle it on Thursday when I'm done with travel and other stuff I >>>> need to deal with? >>>> >>> I will have a look at it. >>> >>> Are we really sure that all APIs behind the EFL_EO_API_SUPPORT are >>> really finsalised? >>> >>> We might need to come up with a list of them and brign them up here for >>> the audience. >>> >> After removal of the EFL_EO_API_SUPPORT ifdef we have the following new >> APIs that we need to support. (git grep "ifdef EFL_EO_API_SUPPORT") >> I did only list areas here as listing every single new function, struct, >> event, etc would just be to big. >> >> Ecore: >> o ecore_poller >> o ecore_loop_timer > I can't find that one. Do you have a pointer ?
Ecore_Eo.h (behind the EFL_EO_API_SUPPORT define) includes efl_loop_timer.eo.h > >> o ecore_exe > All the ecore one should stay under BETA for now. Switched the above to BETA >> o efl_loop >> o efl_loop_args >> o efl_loop_user >> o efl_loop_fd These four are now going to be public API. The problem here is that they need eina_promise exposed which is still in flux. I will keep this patch in a branch for now. >> >> Ecore_Con: >> o efl_network >> o efl_network_server >> o efl_network_connector >> o efl_network_client >> o efl_network_url > All Ecore_Con/Efl_Network need to stay under BETA we haven't had the > time to take care of them. Switched from EO to BETA. >> Edje: >> o edje_object > Will need to be renamed and cleaned as Efl.Canvas.Layout. OK >> o edje_edit > Shouldn't be an Eo object. The src/lib/edje/edje_edit.eo.h only holds a edje_edit_class_get() function. Maybe that was needed to be accessed from EO? If it is superfluous we should remove it. > >> Eio: >> o eio_job >> o eio_sentry >> o eio_model > Some rename are still going to happen with those, but otherwise that > is fine for now. > >> Emotion: >> o emotion_object > This should have been renamed with Efl.Canvas.Video. I did think the > patch did land for that, will have to look at it. src/lib/emotion/emotion_object.eo.h still holds functions and events for emotion_object. Superfluous? >> Evas: >> o canvas/efl_ui_draggable >> o canvas/efl_ui_clickable >> o canvas/efl_ui_scrollable >> o canvas/efl_ui_selectable >> o canvas/efl_ui_zoomable >> o canvas/evas_canvas >> o canvas/efl_canvas_rectangle >> o canvas/evas_textblock >> o canvas/efl_canvas_polygon >> o canvas/evas_object_smart >> o canvas/evas_smart_clipped >> o canvas/evas_common_interface >> o canvas/evas_object >> o canvas/evas_canvas3d_object >> o canvas/evas_canvas3d_texture >> o canvas/evas_canvas3d_material >> o canvas/evas_canvas3d_light >> o canvas/evas_canvas3d_primitive >> o canvas/evas_canvas3d_mesh >> o canvas/evas_canvas3d_node >> o canvas/evas_canvas3d_camera >> o canvas/evas_canvas3d_scene > All the canvas 3d stay a BETA API. Switched to BETA (also the examples using it). >> o canvas/efl_canvas_image_internal >> o canvas/efl_canvas_image >> o canvas/efl_canvas_snapshot >> o canvas/efl_canvas_proxy >> o canvas/efl_canvas_scene3d >> o canvas/evas_vg >> o canvas/efl_vg >> o canvas/efl_vg_container >> o canvas/efl_vg_shape >> o canvas/efl_vg_gradient >> o canvas/efl_vg_gradient_linear >> o canvas/efl_vg_gradient_radial > All the VG API should also stay as a BETA API for now. Switched to BETA (also the examples using it). I left the other evas EO APIs under the EOA_PI flag for now. This should get sorted out over the next days/weeks. >> o canvas/efl_event_input >> o canvas/efl_event_pointer >> o canvas/efl_event_key >> >> Elementary: >> o efl_ui_box >> o efl_ui_box_flow >> o efl_ui_grid >> o efl_ui_grid static >> o efl_ui_image >> o efl_ui_win >> o efl_ui_win_standard >> o efl_ui_nstate >> o elc_combobox >> o elc_ctxpopup >> o elc_fileselector >> o elc_fileselector_button >> o elc_fileselector_entry >> o elc_hoversel >> o elc_multibuttonentry >> o elc_naviframe >> o elc_popup >> o elm_actionslider >> o elm_app_client >> o elm_app_client_view >> o elm_app_server >> o elm_app_server_view >> o elm_atspi_app_object >> o elm_atspi_bridge >> o elm_bg >> o elm_bubble >> o elm_button >> o elm_calendar >> o elm_check >> o elm_clock >> o elm_colorselector >> o elm_conform >> o elm_datetime >> o elm_dayselector >> o elm_diskselector >> o elm_entry >> o elm_flip >> o elm_flipselector >> o elm_frame >> o elm_gengrid >> o elm_genlist >> o elm_gesture_layer >> o elm_glview >> o elm_hover >> o elm_icon >> o elm_image >> o elm_index >> o elm_interface_atspi_accessible >> o elm_interface_atspi_accessible >> o elm_interface_atspi_text >> o elm_interface_atspi_widget_action >> o elm_interface_atspi_window >> o elm_interfaces >> o elm_inwin >> o elm_label >> o elm_layout >> o elm_list >> o elm_map >> o elm_menu >> o elm_notify >> o elm_panel >> o elm_panes >> o elm_photo >> o elm_photocam >> o elm_plug >> o elm_prefs >> o elm_progressbar >> o elm_radio >> o elm_route >> o elm_scroller >> o elm_segment_control >> o elm_separator >> o elm_slider >> o elm_slideshow >> o elm_spinner >> o elm_systray >> o elm_thumb >> o elm_toolbar >> o elm_video >> o elm_view_form >> o elm_view_list >> o elm_web >> o elm_win >> o elm_win_standard > A huge rename and cleanup is still to be landed on elm. Some are > obvious some are less. Still the main issue is to review all object > and point to the one that are still incorrect for bindings. That can > be automated I think. This are the one that needs the biggest change, > while the other should just be a namespace change away. OK >> If you are the author of one of these and you believe that the API is >> not ready yet please move it to the EFL_BETA_API_SUPPORT define. We >> should also look through that one and move things out if they are now >> longer deemed beta. >> >> If you are not the author of one of these above but still think they >> should not be part of our API from 1.18 on please speak up now! >> >> I will start to gradually remove the EFL_EO_API_SUPPORT flag from our >> code base over the next days. > Thanks ! regards Stefan Schmidt ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
