Broadcast conflicts with input method

Bug #1518089 reported by Egmont Koblinger
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Terminator
Confirmed
Low
Unassigned

Bug Description

Enable broadcasting for several panes.

Press Ctrl+Shift+U followed by 2639 and then a space.

In this terminal, a sad face appears because all the other terminals get a literal "2639 ".

I've no clue how this could be addressed. Maybe needs vte work, not sure.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Frankly there are so many evil things that can be done with the keyboard input, that sometimes it is surprising that broadcast works as well as it does. This unicode compose system might not be fixable.

Changed in terminator:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Note to self: even killing IBus (one of the usual suspects) does not fix this. It is possible that the Ctrl+Shift+U doesn't even generate an event! Would need to dump the events to check. And even if we can detect the compose initiator, how do we translate the number to the unicode char/glyph.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

My guess is that maybe terminator should try to steal these events and compose the character itself, and then send the result to all vtes, rather than letting vte do it. I have absolutely no clue if it's doable.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

See also bug 1398424.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Bug 1398424 has nothing to do with this. I'm pretty sure that has already been fixed in another project bug (I never spot the Ubuntu package bugs, just the project ones.) IBus has no impact on this problem.

This issue is different. I admit to being at a loss as to how to fix this one. As a workaround a constructed char can be pasted to all terms at once. But this Ctrl+Shift+U unicode input mode, I have no real idea if that is an input system feature, or VTE. The sequence works in Firefox, gedit and Konsole, so it seems it is not handled specifically in VTE code.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

It's a Gtk input method and/or ibus feature (not sure exactly). Vte is an observer, it is aware of such a string being constructed and it's vte's job to display the partial preedit string. I have no clue if it could modify the behavior or if it can only observe.

I _guess_ all vtes correctly receive Ctrl+Shift+U, but it's a thing of the input method that it only has special meaning in the focused widget. (You can have at most one such preedit globally on your desktop. Start one in one app, click on another to focus that, you continue constructing the previous sequence in that window.)

As interesting as this sounds, I vote for working on the really tricky cases like this one after an initial terminator-gtk3 tarball is out for distros/users to pick up :)

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

What about this workaround trick:

Implement a new popup dialog box (or popover, as "search") called "send character by hex code". Terminator would on its own read a hex char code, and send it to all terminals in the broadcast group.

Bind this action to Ctrl+Shift+U by default.

This way this preedit mode just won't kick in inside a vte.

Revision history for this message
Stephen Boddy (stephen-j-boddy) wrote :

Yup that does seem like a possibility (although coneverting the hex to unicode is a little unknow for me at the moment.

Also agreed that this is low priority at the moment.

Changed in terminator:
importance: Medium → Low
Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

Read a string.

Make sure it's valid hex number, and in a reasonable range (let's say from 0 to 10FFFF). Also perhaps exclude the surrogate values (D800..DFFF).

Use strtoull(..., 16) or whichever similar to parse it and convert to an integer.

Use g_unichar_to_utf8() to convert it to UTF-8.

Feed it to vte.

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

Note that it won't fix other special input methods (e.g. "Japanese (Anthy) (IBus)" is a really weird one). That would require a more complex change.

Probably terminator shouldn't automatically broadcast the events, but vte should call a callback (or emit a signal) that it received a certain character and terminator should catch it and send it to all others. Sounds like it needs vte work...

Revision history for this message
Egmont Koblinger (egmont-gmail) wrote :

> Read a string. [...]

As a bonus, it would be cool if after every single keypress the dialog showed the corresponding character, so that you see if you make a mistake before pressing Enter and feeding to vte.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.