[PATCH 1/3] text: Add content type support to text protocol
Pekka Vuorela
pvuorela at iki.fi
Mon Dec 3 12:26:20 PST 2012
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.
- 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?
- 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.
- 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.
- not really sure what all these uppercase_* are and how they play
together. First two seem suspicious.
- 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.
More information about the wayland-devel
mailing list