[wayland-protocols] text-input: Add v3 of the text-input protocol

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. [1] 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 [2], 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 [1].
> > >
> > > "葵あ" 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.

--Dorota
> 
> >   
> > >
> > > 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.
> 
> 
> Jonas
> 
> > 
> > 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
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180412/7d71ab59/attachment.sig>