@Jaehyun_Cho i agree with Xavi here. I will do the changes tomorrow.
Weird indentation suggests you mixed tabs and spaces... there's a special circle in hell for people of your kind.
efl.input.clickable sounds reasonable, same for the new event names. @woohyun, also okay for you ?
I want this landed and I want it landed yesterday.
Okay, so can we remove the code for this entirely or what?
Hm I suppose it makes sense to move it, but then why not have it be efl.input.clickable to go with efl.input.interface?
Same as efl.text, seems okay?
Sorry, I am not familiar with X11 so I do not see the difference between a key name and a raw key name... example?
Looking at this again, it seems like this is somewhat similar to how on gfx.entity objects we have position, size, and geometry. It's nice to be able to set/access both axes in one call, so I think we should leave it.
Shouldn't this also verify that there is nothing rendered outside the content area?
What problem does this solve? Is there a test case?
minor readability concerns but nothing that looks like a blocker
I've read all image-related eo files and I cannot find any property named "area". What did you have in mind, @zmike?
Please use ck_assert_int_eq for these checks so that errors are more verbose when they occur.
Shouldn't this be fill_area or something like that since we use that terminology in image API? cc @segfaultxavi for doc cop action
@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 [...] When the user passes false as argument, then the user *needs* to handle the value of the promise.
OK, understood. I am OK with using an Eina_Future.
I thought about that, but I'm not entirely sure how to approach it. Will need to debug the existing issue to see what's going on.
This will need to adapt after D9058 lands.
Also, it could check that there's only one selected button in the group. That's an issue I am facing now.
This still does not work for me (buttons are not mutually exclusive), I am currently debugging. I would appreciate if anybody else tested this patch and told me if it works for him.
in MVVM case, as cedric pointed,
child of Efl.Model will be the invariable value for specific item,
but in view object, numeric index can be accessible.
We don't need this one. There has been no requests for this widget.
Added the low option and still no go. Maybe it affects wayland only??
yeah. what @jf_simon said - i get them as i have enabled all 3 levels of notification... :) so... works for me. :) this is perhaps something to address in future to make it possible for one module to modify config of another... or roll notification config and functionality into core E and out of a module? yes - small usability issue. I might actually say that the mixer should show its OWN popup when changing volume so u see the slider... and not use system notifications. but this is a polish/prettiness thing.
If i render correctly, you have to change the noification Level in the notification settings to get the popup.
This is still relevant.
i wasn't aware of this diff :-)
Sat, Jun 15
@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 ?
Fri, Jun 14
@segfaultxavi i rebased now the whole thing and tested again, this seems to work for me.
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.
fix bug, remove printf