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

[Jan Arne Petersen]

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">
> 
> - Could have some description what these mean in more detail.

Yes, I will add more documentation to the protocol.

> - Osk abbreviation on enum doesn't feel nice. If it means not showing
> virtual keyboard then it's not technically a content hint either. How
> does toolkit implement click on focused entry to get keyboard? Default
> value of inhibit, clearing the bit on mouse click?

Yes, it does not seems useful as a hint at all. I will remove it.

> - Default value on content_hint does not seem to be 0. I'd prefer text
> entries prohibiting features like auto caps or error correction instead
> of needing to ask for them.

Yes, sounds like a good idea, I will adjust that.

> - sensitive_data could make sense in addition to hidden_text, or even
> replacing it. Passwords can be shown in clear text but it's even then
> not nice storing them in prediction engine.

Sounds good. I will add that.

> - not really sure what all these uppercase_* are and how they play
> together. First two seem suspicious.

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.

Jan Arne

-- 
Jan Arne Petersen
Openismus GmbH
http://www.openismus.com