On Thu, 12 Apr 2018 10:35:04 +0200 Jonas Ådahl <jad...@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 <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. [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@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
pgpucz63ceWgB.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel