There's no way to type "tab", use arrows, or enter ctrl-c.

Many useful keys are missing (tabs, arrows, home, end, ctrl-X). Sqeekboard issue says it should be handled here... squeekboard#51 (closed)

Does it say it should be handled here though

Kinda a dup of https://gitlab.gnome.org/ZanderBrown/kgx/issues/6

The actual squeekboard issue is squeekboard#126 (closed)

I'm open to which parts go where, as long as it's acknowledged that nothing but the terminal will ever have a need for a real ctrl button.

I'm pretty there are applications where ctrl/alt would be useful. emacs would be one example (it has gtk support, does not always run in terminal...). But yes, terminal is best example.

I'm glad that you mentioned a non-terminal example, because it forces us to consider that ctrl/alt are not something limited to the terminal layout (and so the input hint loses a lot of its purpose).

a real ctrl button

Sounds intriguing

The idea was then KGX provides some hint for squeekboard to show an extra row, I'm not sure how practical doing this in KGX would be

1. How would I deliver events? gdk doesn't let you construct fake ones
2. How would I know if I should show the controls (ideally should sync to OSK)

relevant: squeekboard#126 (closed)

there's a content_purpose terminal in text-input-unstable-v3.xml wayland protocol for that:

https://github.com/wayland-project/wayland-protocols/blob/master/unstable/text-input/text-input-unstable-v3.xml#L231

This currently does not seem to end up in Gtk 3 nor 4 atm:

https://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkInputPurpose

If kgx/vte used that squeekboard would know that a full keyboard is useful.

Right, that's exactly what I was thinking of

What I meant when I said that no other application (okay, use case) needs a real Ctrl key is that the feature is not necessarily trivial to implement in the input method. When using text-input to enter text (as a well-behaved input method should), then there will be no code to support modifiers in the input method at all. The input method will still be 100% touch-functional, because no application that doesn't carry historical baggage of physical keyboards will ever need modifier keys.

In philosophical terms, I'm not 100% sure whose responsibility is to provide for such a quirk. I guess for the time being, the keyboard could do it...

I'm not sure that KGX can do it, maybe some GtkIMContext trickery could work to inject the event but that seems like asking for trouble

If squeekboard doesn't do modifiers how does shift work? Just send an 'A' event instead of 'shift+a'?

Just send an 'A' event instead of 'shift+a'?

Yes. With text-input (WIP), it's not even possible to send shift+a, but you can send a full string like "Alphabet".

I'm not sure that KGX can do it, maybe some GtkIMContext trickery could work to inject the event but that seems like asking for trouble

wouldn't we just fix GTK4 to handle GTK_INPUT_PURPOSE_TERMINAL and set that on the vte widget?

I've already reached out on GIMPNet and that seems perfectly possible (for 3 and 4) and from my perspective the idea solution

But then @dorota.czaplejewicz will have to handle ctrl in squeekboard

I don't mind doing that, at least short term. Just wanted to give some perspective on what can be expected of input method authors in general.

I think a terminal input mode somewhat implies the ability to do things like ctrl so from my non-im perspective it would be odd to GTK_INPUT_PURPOSE_TERMINAL and not get ctrl along with fn keys etc

If we take input purposes as the ultimate source of truth, then yes. There's still value in considering other arrangements, like some "NEEDS_PHYSICAL_KEYBOARD" purpose which would request an emulated keyboard for any application that doesn't support touch interaction properly.

Here I'm hinting at one view of the situation: if some functionality requires a physical keyboard (amulated or not), can the application be considered touch-friendly?

Well considering the "application" here is bash I think it's quite clearly a no on being touch friendly :-)

bash is not the application we're talking about though; the user interfaces to it via the terminal emulator, and this is the part of the system which can accommodate for the user.

I've already reached out on GIMPNet and that seems perfectly possible (for 3 and 4) and from my perspective the idea solution

Do you think this could be implemented in kgx? I mean GTK_INPUT_PURPOSE_TERMINAL

Just checking in on the status of GTK_INPUT_PURPOSE_TERMINAL being implemented in kgx.

Status: Patch submitted to Vte, KGX should get for free (obs will require latest/patched Vte)

Thank you! The vte issue is here: https://gitlab.gnome.org/GNOME/vte/issues/212

Squeekboard 1.8.0 was released, which takes this on from the other side by allowing the user to select the terminal layout always.

moved to Librem5/debs/kgx#1