@segfaultxavi @ali.alzyod

Do you have any opinion on this ?
These ecore_imf related definitions have been used in Tizen a lot.
So, most of them seem to be needed from EFL# developers.

But, If there are some weird names, then I also like to modify them.

• Panel_Layout_Type looks fine.
• Panel_Language_Type needs more docs. What does this enum mean?
• Capitalize_Type looks fine.
• Panel_Return_Key_Type looks fine.
• Panel_Return_Key_State: I would rename auto to prevent_empty so it gives more information.
• Hints_Type:
  • Why are these flags? They look like they can be combined, however, most combinations do not make sense.
  • I would rename this one to autocomplete, autofill or content_type, since this is what this is about, right?

• Efl.Input_Text:
  • Almost all methods are related to the Input Panel. Why isn't this interface called Efl.Text_Input_Panel?
  • input_panel_layout_variation: What is this?
  • input_hint: Same comment as in Hints_Type.

Panel_Return_Key_State: I would rename auto to prevent_empty so it gives more information.

I agree with this opinion for better intuition.

Why are these flags? They look like they can be combined, however, most combinations do not make sense.

I guess that "none", "auto_complete", and "sensitive_data" can be combined with the rest. So, the numbers are set with current definition.

I would rename this one to autocomplete, autofill or content_type, since this is what this is about, right?

I am sorry to not understand well about this. Do you want to change "auto_complete" to "autocomplete" ?
And .. where did "content_type" come from ?

Almost all methods are related to the Input Panel. Why dk isn't this interface called Efl.Text_Input_Panel?

I'm also ok with the new name :)

input_panel_layout_variation: What is this?

In elm_entry_common.h , you can see below enums.
"input_panel_layout_variation" seems to set one of them following the current Input_Panel_Layout. (It is "int" to cover different types of enums)

@segfaultxavi @bu5hm4n
I think this should not be a good way, but I don't have any idea for better support. Do you have any idea ?

/**                                                                             
 * @typedef Elm_Input_Panel_Layout_Normal_Variation                             
 * @brief Enumeration for defining the types of Elm Input Panel Layout for normal variation.
 * @since 1.12                                                                  
 */                                                                             
typedef enum                                                                    
{                                                                               
   ELM_INPUT_PANEL_LAYOUT_NORMAL_VARIATION_NORMAL,          /**< The plain normal layout @since 1.12 */
   ELM_INPUT_PANEL_LAYOUT_NORMAL_VARIATION_FILENAME,        /**< Filename layout. Symbols such as '/' should be disabled. @since 1.12 */
   ELM_INPUT_PANEL_LAYOUT_NORMAL_VARIATION_PERSON_NAME      /**< The name of a person. @since 1.12 */
} Elm_Input_Panel_Layout_Normal_Variation;                                      
                                                                                
/**                                                                             
 * @typedef Elm_Input_Panel_Layout_Numberonly_Variation                         
 * @brief Enumeration for defining the types of Elm Input Panel Layout for number only variation.
 * @since 1.8                                                                   
 */                                                                             
typedef enum                                                                    
{                                                                               
   ELM_INPUT_PANEL_LAYOUT_NUMBERONLY_VARIATION_NORMAL,              /**< The plain normal number layout @since 1.8 */
   ELM_INPUT_PANEL_LAYOUT_NUMBERONLY_VARIATION_SIGNED,              /**< The number layout to allow a positive or negative sign at the start @since 1.8 */
   ELM_INPUT_PANEL_LAYOUT_NUMBERONLY_VARIATION_DECIMAL,             /**< The number layout to allow decimal point to provide fractional value @since 1.8 */
   ELM_INPUT_PANEL_LAYOUT_NUMBERONLY_VARIATION_SIGNED_AND_DECIMAL   /**< The number layout to allow decimal point and negative sign @since 1.8 */
} Elm_Input_Panel_Layout_Numberonly_Variation;                                  
                                                                                
/**                                                                             
 * @typedef Elm_Input_Panel_Layout_Password_Variation                           
 * @brief Enumeration for defining the types of Elm Input Panel Layout for password variation.
 * @since 1.12                                                                  
 */                                                                             
typedef enum                                                                    
{                                                                               
   ELM_INPUT_PANEL_LAYOUT_PASSWORD_VARIATION_NORMAL,    /**< The normal password layout @since 1.12 */
   ELM_INPUT_PANEL_LAYOUT_PASSWORD_VARIATION_NUMBERONLY /**< The password layout to allow only number @since 1.12 */
} Elm_Input_Panel_Layout_Password_Variation;

input_hint: Same comment as in Hints_Type.

I hope above feedback would be an answer for this.

in regards of input_panel_layout_variation, To me it seems like this is just a predefined filter that gets applied to the implementor. Maybe we could make this a utility function that relies on a *not yet defined* filter callback on entry ? And we remove that for now (or make it @beta)?

@bu5hm4n
I cannot clearly understand your explanation about the new way (because of lack of knowledge. Sorry)
But, I fully agree to mark it as @beta for checking it later again.

Forget my comment, i was maybe not fully awake when i wrote that :-D

Why are these flags? They look like they can be combined, however, most combinations do not make sense.

I guess that "none", "auto_complete", and "sensitive_data" can be combined with the rest. So, the numbers are set with current definition.

According to the EO docs, sensitive_data means that "Typed text should not be stored". Therefore I don't think it makes sense to combine with any autofill option, no? Because, to populate the autofill database you need to store something.
And auto_complete is implied by any of the autofill_* options, no?
This is why I don't understand why this enum is made of combinable flags. I think a regular enum with none, credit_card_expiration_date, etc... is enough.

I would rename this one to autocomplete, autofill or content_type, since this is what this is about, right?

I am sorry to not understand well about this. Do you want to change "auto_complete" to "autocomplete" ?
And .. where did "content_type" come from ?

I would rename the Efl.Input_Text.Hints_Type enum to Efl.Input_Text.Content_Type, for example. "Hints" is too generic, and this enum specifies the type of content, no?

input_panel_layout_variation: What is this?

In elm_entry_common.h , you can see below enums.
"input_panel_layout_variation" seems to set one of them following the current Input_Panel_Layout. (It is "int" to cover different types of enums)

@segfaultxavi @bu5hm4n
I think this should not be a good way, but I don't have any idea for better support. Do you have any idea ?

OK, now I see. variation is a subtype for the Panel_Layout_Type enum. So we have 3 subtypes for the Normal layout, 4 subtypes for the Numberonly layout, etc.
I don't think adding a filter is enough since a variation can potentially display a different keyboard layout on the screen.
It is true that the int is ugly. At the very least, the Variation enums should be defined in EO so they are available to bindings.
In C we would use a union but we don't have that in Eolian, right?
We can continue using the int but add good docs explaining that this value must be one of the predefined variation enums.

input_hint: Same comment as in Hints_Type.

I hope above feedback would be an answer for this.

I would rename the input_hint field to input_content_type, as above.

@segfaultxavi @bu5hm4n
I have talked with the ecore_imf maintainer in Tizen, and he speak to me that "this hint_type has not been used at all".
The "autofill" feature has not been handled by ime (i.e another module outside EFL is in charge).
So, I think we can remove it from this eo file :)
(Sorry for not asking first)

@ali.alzyod
Could you remove it with relating methods ?
Plus, we need to define "Elm_Input_Panel_Layout_XXX_Variation" (in elm_entry_common.h) in this eo file newly.
Then, @segfaultxavi can give a help to make good docs for "input_panel_layout_variation".

Everyone here is ok with above opinion ?

It feels weird tu remove functionality that was in legacy. I would keep input_hint as Beta and rename it to input_content_type, but not remove it.

@woohyun

Do we want these variations set method to expect int? (I do not like it, it is ambiguous what data type is expected)?
Note: other frameworks also use int like in android https://developer.android.com/reference/android/widget/TextView.html#attr_android:imeOptions (So it is not new thing)

There are other solution but will increase the size of content_type enum

enum @beta Efl.Input_Text.Panel_Layout_Type
{
   //other types
   password_normal,
   password_number_only,
}

Hmmmm... adding all variations to Efl.Input_Text.Panel_Layout_Type is an option, but it has some problems.

• Its size will increase, as you say.
• It will be harder to detect the "base" type of a layout, since it will involve a lot of if's.
• We could alleviate the above problem using the lower bits of the enum to store the "base" type (same as it is now), and use the higher bits to store the variation:

normal,
number,
email,
password,
...
variation_password_number_only = 0x100,
variation_normal_filename = 0x100,
variation_normal_person_name = 0x200,
variation_numberonly_signed = 0x100,
variation_numberonly_decimal = 0x200,
variation_numberonly_signed_and_Decimal = 0x300,

But I don't think we can have repeated values in an Eolian enum.

Therefore I still think using an int is the less bad option.

@segfaultxavi So we will have a method to get/set variations, set take int parameter, and get return int value ?

Not a method, but a property, yeah.
I don't like it but I can't think of anything else I like more :/

I have tried to get better idea on this.
But, after checking the problems that @segfaultxavi listed up, "using an int" looks the best option for now :)

Another opinion on this ?

It feels weird tu remove functionality that was in legacy. I would keep input_hint as Beta and rename it to input_content_type, but not remove it.

D11130

@segfaultxavi

Are you ok with current definition ~ then, I hope to move this to "stabilized".

I have no further comments.

Move to "stabilized" !! Thanks :)

This type cannot be unbeta'ed. There are other types required. Remove @beta and check it out yourself.

Should we create task for each enum ?

@bu5hm4n For :

Efl.Input_Text.Panel_Layout_Normal_Variation_Type
Efl.Input_Text.Panel_Layout_Numberonly_Variation_Type
Efl.Input_Text.Panel_Layout_Password_Variation_Type

We already added them in D11066, but task description was not updated.

Okay, i cannot comment much on the types here, as i really do not know this kind of stuff.

In T8541#150375, @bu5hm4n wrote:

Okay, i cannot comment much on the types here, as i really do not know this kind of stuff.

@woohyun @segfaultxavi can you comment at this one.

It's OK, I already said I have no further comments.

@segfaultxavi the content of this ticket has changed. There are now more enums.

If we're talking about the enums added in D11066, I know, I was the one that approved them :)

I think we are speaking about the 6 enums in the top of this ticket.

All good! All of them have been reviewed.

I apologize for answering too hastily. There are indeed things that can still be improved:

• Panel_Layout_Type
  • phonenumber -> phone_number
  • numberonly -> number_only
• Capitalize_Type
  • allcharacter -> all
• Panel_Layout_Normal_Variation_Type
  • filename -> file_name
• Panel_Layout_Password_Variation_Type
  • numberonly -> number_only

Ans there are still some legacy @since tags in the docs.

In T8541#150388, @segfaultxavi wrote:

I apologize for answering too hastily. There are indeed things that can still be improved:

• Panel_Layout_Type
  • phonenumber -> phone_number
  • numberonly -> number_only
• Capitalize_Type
  • allcharacter -> all
• Panel_Layout_Normal_Variation_Type
  • filename -> file_name
• Panel_Layout_Password_Variation_Type
  • numberonly -> number_only

Done in D11280

Ans there are still some legacy @since tags in the docs.

I did not find any @since tag in efl_input_text.eo

I probably saw those @since in an outdated diff, sorry.

Thanks! I can't see anything else wrong now.

@segfaultxavi @bu5hm4n @woohyun
Can we stabilize this one now?

Sure!

:) Ok. Let's move this to "stabilized". Thank you very much !!