[PATCH 1/3] text: Add content type support to text protocol

[Pekka Vuorela]

On 04.12.2012 23:24, Jan Arne Petersen wrote:
> On 12/03/2012 09:26 PM, Pekka Vuorela wrote:
>> On ma, 2012-12-03 at 15:15 +0100, Jan Arne Petersen wrote:
>>> From: Jan Arne Petersen <jpetersen at openismus.com>
>>>
>>> Support content types in text protocol. Content is defined by a hint
>>> bitmask and a purpose field.
>>
>>> +++ b/protocol/text.xml
>>> @@ -83,8 +83,42 @@
>>>         <arg name="height" type="int"/>
>>>       </request>
>>>       <request name="set_preedit"/>
>>> -    <request name="set_content_type"/>
>>> -
>>> +    <enum name="content_hint">
>>> +      <entry name="none" value="0x0"/>
>>> +      <entry name="auto_complete" value="0x1"/>
>>> +      <entry name="auto_correct" value="0x2"/>
>>> +      <entry name="no_suggestions" value="0x4"/>
>>> +      <entry name="lowercase" value="0x8"/>
>>> +      <entry name="uppercase_chars" value="0x10"/>
>>> +      <entry name="uppercase_words" value="0x20"/>
>>> +      <entry name="uppercase_sentences" value="0x40"/>
>>> +      <entry name="hidden_text" value="0x80"/>
>>> +      <entry name="inhibit_osk" value="0x100"/>
>>> +    </enum>
>>> +    <enum name="content_purpose">
>>> +      <entry name="normal" value="0"/>
>>> +      <entry name="alpha" value="1"/>
>>> +      <entry name="digits" value="2"/>
>>> +      <entry name="number" value="3"/>
>>> +      <entry name="phone" value="4"/>
>>> +      <entry name="url" value="5"/>
>>> +      <entry name="email" value="6"/>
>>> +      <entry name="name" value="7"/>
>>> +      <entry name="password" value="8"/>
>>> +      <entry name="pin" value="9"/>
>>> +      <entry name="date" value="10"/>
>>> +      <entry name="time" value="11"/>
>>> +      <entry name="datetime" value="12"/>
>>> +      <entry name="day" value="13"/>
>>> +      <entry name="month" value="14"/>
>>> +      <entry name="year" value="15"/>
>>> +      <entry name="hex" value="16"/>
>>> +      <entry name="terminal" value="17"/>
>>> +    </enum>
>>> +    <request name="set_content_type">
>>> +      <arg name="hint" type="uint"/>
>>> +      <arg name="purpose" type="uint"/>
>>> +    </request>
>>>       <event name="commit_string">
>>>         <description summary="commit">


> I got them from
> http://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkInputHints and
> http://developer.android.com/reference/android/text/InputType.html#TYPE_TEXT_FLAG_CAP_CHARACTERS
>
> I am not sure, how useful these capitalization modes really are. I will
> investigate further on that.
>
>> - not sure if all the content_purposes make sense. E.g. Pin is also
>> hidden text (/sensitive_data) and number. Cannot think how separating
>> these helps the input method.
>> As related, not sure if explicit purposes or ORred flags on accepted
>> character ranges as in Qt make more sense.
>
> The split in hint and purpose is done similar to the Gtk+ approach:
> http://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkInputPurpose and
> http://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkInputHints
>
> In Android there is just one bitmask with class, variation and flags:
> http://developer.android.com/reference/android/text/InputType.html
>
> In EFL one can choose an input panel directly:
> http://docs.enlightenment.org/auto/ecore/group__Ecore__IMF__Context__Group.html#ga7df11437c6ef486fe84fea981b99598c
>
> Qt uses one bitmask with flags for alter input and with flags for
> restricting input to character sets which can be ORed together:
> http://qt-project.org/doc/qt-5.0/qt.html#InputMethodHint-enum
>
> I prefer to explicitly specify a purpose. ORred character ranges seems
> to be more flexible, but for most combinations of character ranges it
> seems not really feasible to show a special purpose panel/layout on a
> virtual keyboard.

Thanks. The origins help to understand reasons why things exist here.

I'd be careful of having everything copied verbatim. Some of those might 
be there for historical reasons, and some exist in toolkits because of 
something else is not offered to developer. None of these toolkits seem 
to have an orthogonal flag to use to indicate password, so that could be 
the reason why specific Password and PIN types exist.

Now that got some documentation from toolkits, at least the 
uppercase_chars does make some sense with that setup. Being suggestions 
and together with "lowercase" would correspond roughly to 
PreferUpper/Lowercase of Qt. lowercase_chars would be more consistent 
naming, though.

On Gtk+ found also this:
https://mail.gnome.org/archives/commits-list/2012-August/msg07156.html
Seems quite new. Different uppercasing flags seem to have appeared 
without discussion in late phase.

I agree that it doesn't seem feasible to support all combinations of 
ORred values, but then again I'm not either expecting virtual keyboards 
implementing IP, hex or date layouts (on last the input to be done is 
quite vague). "Name" purpose could have some benefit on prioritizing 
contact names for prediction.

I guess I'm mostly ok with the explicit purpose, provided that the flag 
part allows the orthogonal features that make sense. If the password 
parts are left as purposes, there will be some redundancy, but could 
live with that.

On Qt front what would be missing, and I see of some benefit, are 
UpperCase/LowerCaseOnly which could disable shift, and 
PreferLatin/LatinOnly, which could e.g. on non-latin input method, 
together with number field, ensure that latin numbers are to be input.
Non-latin dialable characters might be or might not be supported as well 
on the application side, so those are quite natural as flags.