[wayland-protocols] text-input: Add v3 of the text-input protocol
jadahl at gmail.com
Thu Apr 12 08:35:04 UTC 2018
On Thu, Apr 12, 2018 at 12:13:49AM +0200, Carlos Garnacho wrote:
> On Wed, Apr 11, 2018 at 8:52 PM, Weng Xuetian <wengxt at gmail.com> wrote:
> > (forgot to reply to the list)
> > On Wednesday, 11 April 2018 11:35:58 PDT Dorota Czaplejewicz wrote:
> >> On Wed, 11 Apr 2018 11:26:22 -0700
> >> Weng Xuetian <wengxt at gmail.com> wrote:
> >> > On Monday, 9 April 2018 07:20:53 PDT Dorota Czaplejewicz wrote:
> >> > > On Sun, 11 Mar 2018 20:30:14 +0100
> >> > >
> >> > > Carlos Garnacho <carlosg at gnome.org> wrote:
> >> > > > This new protocol description is a vast simplification over v2,
> >> > > > highlights
> >> > > > are:
> >> > > > - All pre-edit text styling is gone, the protocol doesn't seem the
> >> > > > place
> >> > > >
> >> > > > to convey UI state. Clients are in better knowledge of how to make
> >> > > > the
> >> > > > pre-edit string distinguishable from regular text.
> >> >
> >> > As an long-time input method developer and CJK user, I'd prefer to keep
> >> > the
> >> > styling. In Chinese or Japanese, partially converted text are common and
> >> > styling is useful to help user to distinguish which text is currently
> >> > being
> >> > converted.  But for the sake of in-app consistency, I'd say we don't
> >> > need that much capability about styling though. Among all input methods
> >> > supported by fcitx , only underline/highlight is being commonly used.
> >> > Recently I started to use some strike style in only one single input
> >> > method though, it can also be useful in certain cases.
> >> I think this use case is covered. For indicating what's currently being
> >> changed, this protocol is using "preedit string". In GTK, the preedit text
> >> is displayed with an underline, making is always clear what the suggestion
> >> pertains to.
> > I think you can take a closer look at .
> > "葵あ" is the complete preedit text. The input method is converting "葵" and
> > giving the candidates for it, the あ part is not yet handled by input method
> > (but typed by user and appears in the preedit). That's why "葵" is being
> > highlighted.
> IIUC, is あ simply unhighlighted till handled by the IM (and the
> suggestion menu changes accordingly)? do preedit text styles in other
> fcitx IMs convey the same or different info?
"葵あ" is both part of the pre-edit string, thus would be highlighted by
e.g. GTK+ as far as I know, what we probably want is a semantical way to
communicate that one part of the pre-edit string is currently being
"fine grained". For example, take the following longer string:
Which means "sell frying pan". What I meant to write, however, was "buy
keyboard", which with some input method is typed in exactly the same
way. To correct the pre-edit string, I'll need to go through the various
parts of the pre-edit string, and a way to highlight what is being fine
grained I think is what is being asked for by Xuetian.
In the above, what the input method might do is first let me correct
賣, letting me select 買. This should be indicated by somehow making me
aware I'm poking at the first character. If it's smart enough, it'd
later let me fine grain the last two characters as one "word", letting
me select "鍵盤", and in this case, both the second and third character
should be highlighted in some way.
Currently in GTK+ with I-bus under gnome-shell, this is currently done
by guessing what character I'm correcting.
> I wonder if we are missing some on-the-wire state, rather than text
> styling support per se. And given the can of worms styling brings in
> (hard to know how to stand out from the IM side, a11y and color
> blindness issues, ...), I would personally rather have a hint system
> than let the IM meddle with a foreign UI.
I think some hint, or some how communicating what is going on without
forcing the toolkit to draw in some specific way, is better as well.
> > In a single CJK text composition, CJK people would type the full sentence
> > ahead instead of word by word because this helps input method to understand
> > the whole context and improve the prediction.
> I'm no CJK expert, so this might not apply neatly, but note there is a
> set_surrounding_text request to help IM get context outside the
> preedit string. This may even be combined with
> delete_surrounding_text+commit_string to alter text outside preedit,
With CJK, the whole sentance would normally live in the pre-edit for
quite some time before being committed, as described above, so any
surrounding text doesn't make much difference here.
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
More information about the wayland-devel