@segfaultxavi this depends on the parameter, when delete_on_transition_end is true, then the user does not need to care about the value of the promise, only the point of time. When the user passes false as argument, then the user *needs* to handle the value of the promise. However, you have to note here, that when the user does not *want* to take care of that returned value, the widget that got unpackt will just float arround on the UI, which is probebly not what a user wants ... :)

@bu5hm4n I'm not arguing against using a Promise, I'm just trying to see if there are alternatives :)

@SanghyeonLee Can you verify that all usages of the Efl.Ui.Item class do only require a numeric index as parent, never something like an object ?

It was also brought up that it is confusing to have this in the ui namespace, we should probebly move this to the gfx namespace ...

Undependend from this, we do not need this widget, lets remove it from the list.

@segfaultxavi in all honesty, not returning the promise is not an option here, if we require that in future we need a new API, which basically does the same. It is perfectly possible right now to do that, bindings do lack this feature, but they should add that.

@Jaehyun_Cho Can you answer if you are happy with pop / push ?

@cedric @segfaultxavi @Jaehyun_Cho so my actions items here are:

@cedric @segfaultxavi @Jaehyun_Cho so my actions items here are:

@segfaultxavi i rebased now the whole thing and tested again, this seems to work for me.

remove asdf

In D9060#167031, @zmike wrote:

One of the main points of the efl_add extended construction mechanics was to allow things like this, where you could set all the properties during construction. The only thing that perhaps was not clearly defined from here would be e.g., whether packing the widget into a box during construction is allowed, but probably we did want that functionality too so that every function can be called during construction.

rebase

rebase

fix bug, remove printf

Just screwed by phab.

Just screwed by phab

Good point! Agreed!

I am actually wondering if it wouldn't make sense to make efl_ui_radio_state_value_set and efl_ui_radio_group_register actually @constructor as I don't think we want to deal with changing them once the object are created?

https://i.imgur.com/m4vDHwO.gifv

https://media.giphy.com/media/oOX5qIDkzDjeo/giphy.gif

We try to leave some functionality to the imagination of the user; no docs can possibly hope to capture the gestalt of efl's splendor.

I've written my concerns in T7898.

This class needs serious doc love. I do not understand how format_cb and format_string are supposed to interact. Also, Format_Func_Cb only has input parameters, no output, where is the formatted string supposed to be written?

I think you would use the callback?

Future me.

Oh ok.

And I still don't know how would you implement the special values with a format string.

When you say "Let us cut it"... who exactly is us? 😁