Agreed. This is confusing. This is how it works (after examining the code):
OK, I think the special_value property is redundant if we use the Efl.Ui.Format mixin. Probably a leftover from older times.
Yep, just verified. Looks good to me.
@segfaultxavi this is then also looking good ?
This looks OK to me too. Docs need polishing, as usual.
Woops. I missed the extension relation between two interfaces.
That is, "Efl.Ui.Range_Interactive extends Efl.Ui.Range_Display"
A few interfaces are only implementing efl.ui.range_display, others are implementing efl.ui.range_interactive. If we would not have this split, we would have a lot of unimplemented API.
I also feel good with "efl.input.clickable" :)
It should be better than a name with gfx.
Except the wondering why this interface needs to be separated with efl.ui.range_interactive (T7894),
this looks ok for me.
I also think that the only way to give better understanding is "adding simple example or some basic functionalities".
Without any example, nobody could not easily understand what this class is for.
efl.input.clickable sounds reasonable, same for the new event names. @woohyun, also okay for you ?
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?
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.
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.
Sat, Jun 15
@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.
Fri, Jun 14
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?
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? 😁
I agree with both of the above ideas.
I like "primary" more than "any", yep.
After some thought, I think maybe an improvement on this could be using changed and changed,primary, where the latter indicates the left button has been pressed on a standard mouse configuration. This more definitively handles the case of e.g., left-handed mouse configuration for Xorg/Wayland and we can mention that the primary event will continue to work for right-handed configurations.
Does this class need to exist?
This is a good point. Let's cut it.
This seems pretty straightforward?
I think that's also not quite what we want either?
I also think it is very meaningful to discuss Error things for EFL.
However, this task has a purpose to define text related interfaces.
Error things need to be discussed over EFL, so that kind of things can be talked in another channel such as irc or mailing thread.
Interface related tasks are normally urgent if we think about the due date (i.e. next release).
So just steady? How about that?
Thu, Jun 13
I think the issue for me is that changed is still in the signal name, and changed implies that a change was completed. Having changed,stable or similar is weird because it implies that regular changed events are not "complete".