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 <wen...@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 <wen...@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 <carl...@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, > 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 > email@example.com > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel