Page MenuHomePhabricator

efl.ui.text
Open, TODOPublic

Description

class Efl.Ui.Text @beta
├ (P) scrollable
├ (P) input_panel_show_on_demand
├ (P) context_menu_disabled
├ (P) cnp_mode
├ (P) input_panel_language
├ (P) selection_handler_disabled
├ (P) input_panel_layout_variation
├ (P) autocapital_type
├ (P) password_mode
├ (P) input_panel_return_key_disabled
├ (P) prediction_allow
├ (P) input_hint
├ (P) input_panel_layout
├ (P) input_panel_return_key_type
├ (P) input_panel_enabled
├ (P) input_panel_return_key_autoenabled
├ (P) item_factory
├ (M) input_panel_show
├ (M) selection_copy
├ (M) context_menu_clear
├ (M) input_panel_imdata_set
├ (M) input_panel_imdata_get
├ (M) selection_paste
├ (M) input_panel_hide
├ (M) cursor_selection_end
├ (M) selection_cut
├ (M) context_menu_item_add
├ (M) cursor_new
├ (E) changed
├ (E) changed,user
├ (E) validate
├ (E) context,open
├ (E) preedit,changed
├ (E) press
├ (E) redo,request
├ (E) undo,request
├ (E) aborted
├ (E) anchor,down
├ (E) anchor,hover,opened
├ (E) anchor,in
├ (E) anchor,out
├ (E) anchor,up
├ (E) cursor,changed,manual
bu5hm4n created this task.May 3 2019, 11:04 AM
bu5hm4n triaged this task as TODO priority.
bu5hm4n added a parent task: T7847: efl.input.clickable.
bu5hm4n updated the task description. (Show Details)May 3 2019, 11:07 AM

I agree with @ali.alzyod in D8856#161733 that password_mode and password are confusing:

  • Efl.Ui.Text.password_mode: Sets the entry to password mode. In password mode entries are implicitly single line and the display of any text inside them is replaced with asterisks (*).
  • Efl.Text.password: Whether text is a password.

So the first one is a property of the text entry widget, and the second one is a property of any text rendered by EFL (a button label could be in password mode, for example).

Probably the Efl.Ui.Text widget should implement password from the Efl.Text interface instead of providing a different property.
Also, I would change password to password_mode in the interface. Otherwise it looks like the text is password-protected or something.

ali.alzyod added a comment.EditedMay 9 2019, 12:21 AM

@segfaultxavi I think Efl.Ui.Text.password_mode should be removed

Also I suggest instead of rename password to new password_mode, make new function called set_mode that take ENUM, and make password one of these Enums,
These way when we added new mode, interface function will not change, and we only add new Enum to Mode Enum, and we will insure compatibility with new releases

What other modes do you foresee besides Normal and Password?

Besides whether password_mode should be a boolean or a generic mode enum, I still think this property should be removed from Efl.Ui.Text, which should then only override the one in Efl.Text. Do you agree?

I still think this property should be removed from Efl.Ui.Text, which should then only override the one in Efl.Text. Do you agree?
Yes I agree

What other modes do you foresee besides Normal and Password?
Right now we have two, but in future we can add more. (for example no_text like when insert password in terminal, no text will shown but control have text)

for example no_text like when insert password in terminal, no text will shown but control have text

Oh, that would be a nice addition, true!
This might currently be accomplished (I think) by using password mode and an empty replacement char, but an enum is far far simpler to understand.

So we change the bool password into a display_mode enum. What do you think? Are there other opinions?

(By the way, I have been talking about Efl.Text containing the password property but that is actually in Efl.Text_Format.)

I always prefer general functions with Enums/flags for specific option
1- understanding SDK much simpler (specially from documentation)
2- adding features will never break comparability in future

So we change the bool password into a display_mode enum. What do you think?
My only concern is what we write before mode :), should it be display_mode or text_mode, something general that we will never change in future or add new function with similar functionality

Are there other opinions?
We did some comparison between EFL and many other Platforms and SDKs
Currently we are arranging priorities, As soon as we are ready we will share with you our ideas to enrich EFL text features support.

ali.alzyod added a comment.EditedJun 1 2019, 3:06 AM

@segfaultxavi @woohyun @bu5hm4n @zmike

I am thinking of making all text interface APIs return error codes, where it make life of efl developers more easy, to know exactly what is happening if function success or failed.

I will start with simple thing like (EFL_ERROR_SUCCESS, EFL_ERROR_INVALID_PARAMETERS, EFL_ERROR_NO_MEMORY).

The important thing in this stage is to change all signatures of the interfaces to have error code, and no api break will happened in future.

For example:
Function return int or string will instead, fill these values as parameters and return error code.

What do you think ?

I am not so sure this is a good idea, for several reasons:

  • Learned from history: People do not check for returned error-codes, this is just not happening... I cannot tell you why, but it does not happen.
  • in EFL we normally use something like EINA_SAFETY_CHECKS for validating input values, this has the advantage that a error with backtrace is printed. So for a developper its quite easy to see where this has happened. A error code however would not be very helpful, as this will likely not be checked (see #1), and the error message that is usefull will not be printed.
  • Error codes that express different things, are most of the time redundant in the meaning. Imagine you are setting text to an entry object, and the API is like you proposed, what are you going to do in the case EFL_ERROR_INVALID_PARAMETERS is returned, or EFL_ERROR_NO_MEMORY ? Those are states that are not really recoverable in a sane way. Normally you are just interested API wise if its a success or a failure, and that can be (most of the time) notated in the existing return value, or just returned as an bool
  • This will make our API a lot harder to read and use, efl_text_get(obj, &pointer_to_char); is not really nice and useable from a user POV, also considering that you maybe want to directly inline this call into another call. I am also not sure how this will be working in bindings.

I think what is rather important on this ticket right now is:

  • We must ensure that Efl.Ui.Text only relies on Efl. prefixed types, All Elm.* stuff will go soon, and MUST not be used in any eo files.
  • We do not have any tests where we can showcase the features that are exposed via this object, additionally, there are no examples that show how it *feels* to use the API, so how can we see if this API is a pain to use or not... :(

Other concerns:

  • cursor_new, why is this returning a ptr(...) to a text cursor ? I am not sure why this even works ...
  • context_menu_item_add, this feels like an API from earlier days, we should not pass on any callbacks here... This should get some serious rethough, and maybe should be modeled with some interface and event?
  • input_panel_imdata_set / input_panel_imdata_get are also looking rather conerning, we should not have any void_ptr in any .eo files that gets stable.
  • item_factory should get checked if we are passing arround ownership there or not.
  • It looks like we are having our selection stuff splitted over 3 interfaces, why? We should find out why it is like this, and maybe group yet another interface, but this time with *all* API that is used for selection stuff

I am not putting this work on anyones list, and i am not going to work soon on this, as i have other things on my list before that... :)

@bu5hm4n Thank you for your fast feedback
These are my comments on some points

Learned from history: People do not check for returned error-codes, this is just not happening... I cannot tell you why, but it does not happen.
For me and developers I know, it is has been always convenient to check error code (if library support error code)

This will make our API a lot harder to read and use, efl_text_get(obj, &pointer_to_char); is not really nice and useable from a user POV, also considering that you maybe want to directly inline this call into another call. I am also not sure how this will be working in bindings.

I would say function use will be little bit harder to be used to it, since we were using efl without error code.
But still there are other solution, for example fill error as parameter passed to function (**error), and check it later, or create global last error function to check error code happened internally.

Even for binding error code could be very helpful to throw exception for programming languages that uses exception, but with some modifications.

these are examples for C libraries and frameworks that uses error codes, that I worked with some of them and error codes were very helpful.
https://www.freetype.org/freetype2/docs/reference/ft2-error_code_values.html
https://docs.microsoft.com/en-us/windows/desktop/Debug/system-error-codes
https://www.khronos.org/opengl/wiki/OpenGL_Error
https://www.cairographics.org/manual/cairo-Error-handling.html

I would like to hear from everyone, and I think we can at least provide users with easy and convenient way to handle errors in efl

zmike moved this task from Backlog to Needs experts on the efl: api board.Jun 12 2019, 7:36 AM

@ali.alzyod

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, I hope you understand about the situation, and let's focus on defining methods in the description.

Diffusion closed subtask T7562: efl.input.interface as Resolved.
zmike closed subtask T7578: efl.ui.view as Resolved.Sep 26 2019, 8:12 AM