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 <[email protected]>
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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
