[wayland-protocols] text-input: Add v3 of the text-input protocol
dorota.czaplejewicz at puri.sm
Thu Apr 12 08:52:51 UTC 2018
On Thu, 12 Apr 2018 10:35:04 +0200
Jonas Ådahl <jadahl at gmail.com> wrote:
> On Thu, Apr 12, 2018 at 12:13:49AM +0200, Carlos Garnacho wrote:
> > Hi!,
> > 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 follow-up discussion on #sway-devel between Weng and others, this was the general sentiment. I'm planning to submit an updated draft within the week.
> > >
> > > 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,
> > too.
> 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.
> > Cheers,
> > Carlos
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel