This is incredible ?

In D7367#128352, @segfaultxavi wrote:

So objects are removed from the list now before adding them again? To avoid duplicates?

The test case is cool and works fine at first but exhibits many bugs and tons of ERR messages along the way (eg. unpack_all does not delete the current page, etc...)

Efl.Ui.Flip "pack" API is completely broken. I think one of the two APIs should be used: front/back or pack but probably not both.

This is more than 2 years old, with zero follow-up.

I will drop this.

Three components:

• FrameStack, Frame, NavigationBar.
• Client-side implementation since Tizen E won't support it well.
• Use events to propagate things like "back button pressed" in this way: button -> bar -> frame -> stack. App should be able to listen to this publicly defined event (eg. "pop,requested").
• Add "autopop" property, true by default, for each frame, so app can block frame pop on back button click (eg. in order to show a popup "do you want to save?").

Quick recap before I leave.

Yes those APIs are necessary, but they are still "not clean" in Efl.Ui.Widget, see T5363. They must be well documented, and it must be clear whether they should be in Widget or only in the Scrollable interface.

In D5782#99070, @raster wrote:

almost done... just "which efl version is this for" is missing (see above review requests) :)

looks good. can you do these 2 tiny changes?

Test code, for the lazy:

#include <Efl_Ui.h>

I'm surprise it even works for you...
Other than the string compare, good job! This is a HUGE patch, so... good job :)

Looks fine but this should have been two patches, ideally :)

In D5782#98913, @id213sin wrote:

@jpeg

Hmm. I don't get it. What's going on there? MY_CLASS_NAME_LEGACY is correctly defined as "elm_button" (and not "Elm_Button" anyway).

The "elm_button" is supa dupa legacy. It is older than "Elm_Button".
The "Elm_Button" was appeaed and it was returned from "elm_object_widget_type_get()". The "elm_button" became leagacy and it was returned from evas_object_type_get().

Now, "Efl.Ui.Button" is appeared. So, "Elm_Button" and "elm_button" have to be legacy.
If the object is added from "elm_button_add()", it has to show legacy name just like before.
Efl.Ui.Button_Legacy is totally new name. Not Legacy.

How did you get the wrong type name???

Try elm_object_widget_type_get() function. It will return object's given class name.

Hmm. I don't get it. What's going on there? MY_CLASS_NAME_LEGACY is correctly defined as "elm_button" (and not "Elm_Button" anyway).
How did you get the wrong type name???
This change should either be done on ALL legacy widgets or there is some logic error somewhere which needs to be fixed. One way or another, this change is dubious.

Meh. We are down to ~10 APIs or less that clash in the Unified API. It seems easier to me to use a tiny bit of creativity here rather than add complexity to all our binding generators (or API users, in case of C++). Note that in C++ a name clash can be worked around, but a newly introduced name clash will prevent existing apps from compiling (as obj.my_func now resolves to two real functions, C++ compiler will fail to figure out which one).
I think it's more important to continue resolving the clashes, then somehow discard any error/warning for legacy-only EO files, but straight out error in case of a Unified API EO file.

Oops I pressed Submit too early.
I wonder if it's a good idea to have this API unconditionally format the color class name, as it makes it behave differently between the low-level and the high-level.
Low-level: "efl/button/bg/active" (or whatever the real names are, ofc), and high-level is only "active". Passing "efl/button/bg/active" won't work... It should work.
It sounds like a problem similar to "theme" in Efl.Ui.Layout. What do you think?

Please discuss this with @singh.amitesh. He has pending patches for color. Also for now color_class_code resides in Color instead of Color_Class (it belongs to Color_Class, obviously).

looks ok

I don't see any new test case for this? Looks like you should check that ecore_timer_add(NULL) returns NULL, no?

@stanluk is the boss for accessibility :)

Thanks. Stupid Window class.
Fixed in 426ccba6bdbd3bf6a83dd8778d1404e8b9c9c453

Yeah I thought about commenting "why not else if (manager) instead?"... :)

Tested, works. Lgtm but please @bu5hm4n should review this.

lgtm

Okay then I will test this myself. Thanks!

Let me know when this is done. It mostly looks good. Though now I wonder if creating all those EO files was necessary and we couldn't have just used the EO macros to create the classes internally. No big deal, it's just more work making EO files, but it's also much cleaner.

No. I didn't know about this ticket.
I'm not sure this can "easily" be done. @bu5m4n would know best here, of course, but I'm not convinced that on_focus_update is the same as focus_set.

Isn't this basically ready to be merged, now?

So far simple renames have been the preferred method, even if it sometimes leads to less than perfect method names.

In D5749#98465, @Jaehyun_Cho wrote:

Do we need to do typedef for the following classes as well?

Elm_Bg
Elm_Image
Elm_Win
Elm_Progressbar
Elm_Multibuttonentry

it was just warnings anyway. but no, i didn't see more pop up after your patch

Good question. In the base object class we get efl_name_get() for C.
So far in case of a method name clash like this we would just "prefix" the conflicting APIs. Example here Efl.Ui.Win.win_name gives obj.win_name() in bindings, efl_ui_win_name() in C. But the window name is not very useful, while the AP (EEID maybe?) and technology names are very useful.
Not sure what to do... call them "ap_name" or "eeid" and "technology" or "technology_name"? Hmm...
While I find that __ prefix is not a bad idea, it should also apply to all other methods in Efl.Object to be consistent. eolian_gen would need to know about it (so that base functions like efl_del remain as-is, for instance).

In T6617#109642, @raster wrote:

and without osmesa installed you get a NULL egl api handle... this is actually how it SHOULD work. gl is not possible. so ... what about these changes i made actually breaks anything that shouldn't be? were we returning a non-null gl api handle even if osmesa was not found... but then how could that work anyway? i am pretty certain long ago we were returning a null gl api handle when no osmesa was found and perhaps someone changed that to make it always return a handle anyway?

Between fb048e73120b3909 and 24447641d38cb9bf7b evas_gl_new() returned non-NULL even if OSMesa is not present. All actual function calls would fail (context create, etc). Before and after those patches evas_gl_new() always returns NULL.

Thanks for the fix.

@eunue where are we on this?

In T5301#109617, @ajwillia.ms wrote:

I disagree with the combining of toolbar and tab bar. Whilst they may be similar from a ui (and also external api) point of view the function differently.

Tab bar should indicate current tab and allow through api the addition of views attached to a tab button. Whereas toolbar is simply a list of tool buttons probably with separators...

Current status:

eolian: efl_gfx_path.eo:259:7: function 'interpolate' redefined (originally at efl_vg.eo:96:7)
eolian: efl_gfx_path.eo:62:7: function 'bounds_get' redefined (originally at ector_renderer.eo:110:7)
eolian: efl_gfx_path.eo:62:7: function 'bounds_get' redefined (originally at efl_vg.eo:85:7)
eolian: efl_net_control_access_point.eo:161:13: function 'name' redefined (originally at efl_object.eo:63:10)
eolian: efl_net_control_technology.eo:70:13: function 'name' redefined (originally at efl_object.eo:63:10)
eolian: efl_net_session.eo:89:13: function 'name' redefined (originally at efl_object.eo:63:10)
eolian: efl_player.eo:44:14: function 'position' redefined (originally at efl_gfx.eo:21:10)
eolian: efl_text_cursor.eo:37:10: function 'cursor' redefined (originally at efl_ui_cursor.eo:43:10)
eolian: efl_text_font.eo:59:17: function 'font' redefined (originally at efl_text_properties.eo:21:10)
eolian: efl_text_font.eo:66:17: function 'font_source' redefined (originally at efl_text_properties.eo:48:10)
eolian: efl_ui_focus_object.eo:29:13: function 'focus' redefined (originally at elm_widget_item.eo:154:17)
eolian: efl_ui_list_model.eo:32:10: function 'size' redefined (originally at efl_gfx.eo:39:10)
eolian: efl_ui_model_factory_connect.eo:5:7: function 'connect' redefined (originally at efl_ui_model_connect.eo:5:7)
eolian: efl_ui_text.eo:146:10: function 'password' redefined (originally at efl_text_format.eo:102:17)
eolian: efl_ui_zoom.eo:53:10: function 'zoom' redefined (originally at efl_gfx_map.eo:253:7)
eolian: efl_vg.eo:17:10: function 'name' redefined (originally at efl_object.eo:63:10)

efl_gfx_path, efl_vg -> @smohanty
efl_net -> @barbieri
efl_player -> @taxi2se
efl_ui_list, efl_ui_model_factory_connect -> @felipealmeida
efl_ui_text -> @herdsman
efl_ui_zoom -> @singh.amitesh

Efl.Ui.Layout work is completed (only one API: theme).

I think you're the boss.
Everything right now is marked as beta, except for:

• Efl.Ui.Widget.access_info
• Efl.Access.attribute_append
• Efl.Access.attribute_clear

But the last two are actually protected behind an extra EFL_BETA_API_SUPPORT. There are some C API's inside efl_access.h as well, also behind EFL_BETA_API_SUPPORT.
In other words, nothing except Efl.Ui.Widget.access_info is stable, assuming we release the EO API.

In T6441#109564, @ajwillia.ms wrote:

grep -r "Elm" src/lib/efl/interfaces

src/lib/efl/interfaces/efl_config.eo: - Elm_Color_Class list -> no need to return the struct, only the name matters
src/lib/efl/interfaces/efl_config.eo: - Elm_Color_Overlay -> see with Jee-Yong and his color patch (common intf)

As mentioned in T6441, I think this is the current state of Efl.Ui wrt. this task.

• elm_interface_scrollable is not needed, as it is replaced by "has a" Efl.Ui.Scroller (as opposed to "is a" scrollable mixin).
• elm_interface_fileselector is needed as part of the fileselector. No one is working on this currently, and Tizen shows no interest in it. It will only be done if someone steps in voluntarily to do work on it. It shouldn't be a blocker (I full well understand the value of a good fileselector! But it's a big task to improve and adapt the existing one, or replace it by something better!)
• elm_color_class: thanks for the reminder! I'll have a look :)

Not a priority for Tizen. While super useful this is not a blocker for a stable EO API.

Most of this has been handled already, I think, API-wise. All unstable things have been marked as beta.

What was this for? Is it needed?
I see no update on D4966

commit 07e7bbd4b5cc17bbf8c1e48e500396e66f98120e
Author: Thiep Ha <thiepha@gmail.com>
Date: Tue Jan 16 16:33:30 2018 +0900

Widget still has 4 unclear methods defined:

/* FIXME: Scroll API. Not sure how those APIs should be exposed with
 * the new scrollable API. */
scroll_hold_push {
   [[Push scroll hold]]
}
scroll_hold_pop {
   [[Pop scroller hold]]
}
scroll_freeze_push {
   [[Push scroller freeze]]
}
scroll_freeze_pop {
   [[Pop scroller freeze]]
}

Most of this has already been implemented. Good!

Do we need fileselector now? A proper interface would require a LOT of work.

This depends on @cedric's work on the model. Come on.

I think I made a mistake at first by inheriting Pack_Grid from Pack_Linear... it's probably not a good idea after all (removing that inheritance could simplify the code).
We could also have a better namespace? But I'm not sure.
Any specific issue here, @cedric ?

Last missing bit for me is @herdsman's removal of item_provider_cb, and maybe @taxi2se's work with Playable interface.

This is 99% done. Only offenders are Efl.Ui.Text (many API's) and Efl.Ui.List (only one unimplemented API).

Okay. I think this is it.
Stack API is beta. Types I believe are useless (use a subclass). Some methods / properties lack proper documentation. But overall this looks better now.
If you reopen this, please mention specific points to address.

I think @taxi2se handled a lot of this already.

It's not really a big task. It's already the case for all things related to evas as evas object constructor looks for the evas.
Though you are perfectly right that a proper hint in EO would make sense.

It was assuming that if evas_gl_new() returns something then surely evas gl must work. The null checks can remain, but the assumption was absolutely not stupid.

The change in Eo.h is not internal by definition.
It will affect all apps already compiled assuming they had their own .eo files. Unlikely, but still to be considered.

Then just close it :D

So called "list popup" (basically ctx menu) is still missing because some changes on model are still pending. Ping @cedric.

Please reopen if there are remaining issues. And please explain the test scenario (not necessarily the code path) :)

The patches submitted show that application logic must be adapted, which is not acceptable. I'll submit something soon.

you know what? make sure animation objects can't be created without a parent (try to find the evas from this parent. if null, then finalize or constructor should return null) - also change the test cases also.

See T6579 - When using custom themes, this broke the standard bg of some windows added with elm_win_util_standard_add. Somehow not all (weird). I'll fix it soon.

Two small patches merged:
fe346d2ee2 elm_datetime: use legacy elm_button
1375705168 panes: Expose parts in EO file

Okay then please close this if your saying is correct.
@taxi2se also please address Dave's concerns on the ML.

@taxi2se can you ping me again so we check these patches together? thanks

1. "Frame_Stack", no?
2. both: insert_at, insert_after (optional), insert_before
3. good question. probably promote. that's a corner case
4. what is Frame_Navigation? a subclass/style of Frame? then, yes, i guess it could be? not sure :)

Well, it's in. To be honest I am quite dubious that the cache was actually helpful... It's too specific.
But I wonder if merging this patch isn't breaking ABI??

Half done. I think you can do E. I didn't push anything for E but you should see a lot of messages.
Also, you might be interested in changing some NULL check the old (evas) EAPI to print a warning as well (I have evas_callbacks.c in mind).