Another note: I can already see how it's going to be very difficult to keep track of comments and discussion if we do it here in phab. The discussion has already diverged (@cedric and @ali.alzyod asked about different things), should me move it to edevelop? Or do you fellas prefer keeping it here?
Thanks @zmike! Rest of you: I'll answer tomorrow. :)
This is a substantial project (and accompanying RFC), so I'm adding everyone who may have interest in reviewing your proposal.
@woohyun, I'm going to reshuffle things in the text space so I wouldn't worry about making a decision/change yet. I'll take a look at the WPF naming scheme when changing though.
Fri, Aug 16
Cool, thank you!
I will try the work item #2, and try to estimate the things you are worrying about.
The problem is, those works give a really big change on how the interface interacts, as right now event emission is pretty messed up, and a lot more events are emitted than we actually need ... I am not sure if we get arround resolving that before declaring it stable.
Ok ok :)
Thu, Aug 15
I think its quite clear that a boolean flag is either to turn it on or off, DirectTextInput (direct_text_input) sounds very good to me :)
My last comment! EnableDirectTextInput?
Thanks for sharing the current status :)
You are not such a horrible person :)
Env class has an env property. It is multi-valued, so it is not generating a problem for C# yet. But it may in the future.
hmmmm... I don't like any of them, I am a horrible person :)
- EditableText looks like this property should be text, not a boolean
- TextEditable sounds weird in English
- TextIsEditable sounds best to me, but we have nothing like this in the current API
- Editable sounds like the opposite of Enabled
Wed, Aug 14
Oh, I forgot to update this ticket, sorry. Selectable is now basically "new". The text relevant things have been refactored out, the resulting interface is *only* for selecting selectables.
Is this ok for following dependencies - or Do we need to remove this interface perfectly ?
Please look into this task with T7383.
I cannot trace the discussion results so far.
Could you do the action item on the description ?
Plus, if you are thinking of another action item - please share it here.
I think this looks ok - because legacy scroller has proved that this enum is needed with this definition.
Let's make a list of work items here (and add them in the description comment)
I think below things need to be considered together as work items.
Do you have other candidate names for Text classes ?
I also like the idea of WPF, but I hope to hear your ideas.
Hmm. I am still confused which one is better.
And, I could not find similar names in other platforms, so it is much difficult problem for me.
(Plus, I'm not that good person for naming !!)
I'm OK with wraparound but I really think editable_text is better than text_editable (adjective before noun).
Another option is text_is_editable.
Tue, Aug 13
Sounds good to me :)
Are you ok with "wraparound" and "text_editable" ?
Then, I'll add action items, and will do by my own soon.
If my memory is correct -
when we began these interface works, upstream developers discussed together about STYLE.
@herb My point was that anchor popup align is handled differently based on parenting, not that the two methods of aligning are incompatible. Currently there is no clamping to the window with the base popup's align, but this is just because there can be no parent besides the window, so the popup is always aligned correctly without any further checks or adjustments.
Could we move this task to "Stabilized" ?
So, could I add below two work items ?
I hope so :) no more feedback ?
Mon, Aug 12
Hi, I agree to your opinion, the usage of the anchor popup align is different from base popup.
so I think the align feature in anchor popup should be separated from Efl.Ui.Popup.Align
and make the anchor popup has its own priority align features.
Looking at align, this could be moved to the size hint, but the functionality would change pretty radically, particularly in the anchor popup subclass.
I think we could maybe move timeout to just be an implementation of efl_loop_timer_interval_set?