squeekboard issueshttps://source.puri.sm/Librem5/squeekboard/-/issues2021-07-13T10:05:54Zhttps://source.puri.sm/Librem5/squeekboard/-/issues/288How to get it working with Qt application?2021-07-13T10:05:54ZAlexander VashchilkoHow to get it working with Qt application?It's very strange that it working only with GTK applications. It there any fundamental restrictions for this? Or its just not implemented yet?It's very strange that it working only with GTK applications. It there any fundamental restrictions for this? Or its just not implemented yet?https://source.puri.sm/Librem5/squeekboard/-/issues/287Randomized layouts for entering passwords2021-07-11T17:25:21ZAlexander VashchilkoRandomized layouts for entering passwordsThis keyboard is used not only on the phones, but on laptops and PC's too. This feature will be very useful for preventing passwords leaks through the hardware keyloggers, for example through the acoustic keyloggers.This keyboard is used not only on the phones, but on laptops and PC's too. This feature will be very useful for preventing passwords leaks through the hardware keyloggers, for example through the acoustic keyloggers.https://source.puri.sm/Librem5/squeekboard/-/issues/286unable to see key ñ (spanish) in terminal keyboard2021-06-17T19:25:55ZPablo Barcielascow@riseup.netunable to see key ñ (spanish) in terminal keyboardhttps://source.puri.sm/Librem5/squeekboard/-/issues/285wl_surface destroyed before zwlr_layer_surface_v12021-06-04T16:29:35ZWilliam Woldwl_surface destroyed before zwlr_layer_surface_v1According to `wayland.xml`:
> When a client wants to destroy a wl_surface, they must destroy this 'role object' before the wl_surface.
But when the keyboard is hidden, the `wl_surface` is destroyed first:
```
59.5005 zwp_input_method_v2...According to `wayland.xml`:
> When a client wants to destroy a wl_surface, they must destroy this 'role object' before the wl_surface.
But when the keyboard is hidden, the `wl_surface` is destroyed first:
```
59.5005 zwp_input_method_v2@30.1 done() ↲
60.3165 → wl_surface@38.1 destroy()
60.3171 → wl_buffer@43.1 destroy()
60.3176 → wl_shm_pool@44.2 destroy()
60.3185 → zwlr_layer_surface_v1@42.2 destroy()
60.3237 wl_display@1.0 delete_id(id=38) -- destroyed wl_surface@38.1 after 25.9189s ↲
60.3265 wl_display@1.0 delete_id(id=43) -- destroyed wl_buffer@43.1 after 25.8174s ↲
60.3315 wl_display@1.0 delete_id(id=44) -- destroyed wl_shm_pool@44.2 after 25.8233s ↲
60.3355 wl_display@1.0 delete_id(id=42) -- destroyed zwlr_layer_surface_v1@42.2 after 25.9295s ↲
```
This behavior generates an error on Mir, but doesn't seem to currently cause a problem on wlroots.https://source.puri.sm/Librem5/squeekboard/-/issues/282Indicate pressed character via a small popover just above the hit key.2021-05-08T09:16:17ZGuido GuntherIndicate pressed character via a small popover just above the hit key.Similar to what osk-sdl does it makes it more visible what was typed when looking at the osk (rather than the TextEntry) and would help https://source.puri.sm/Librem5/squeekboard/-/issues/281 since the same popover could indicate the alt...Similar to what osk-sdl does it makes it more visible what was typed when looking at the osk (rather than the TextEntry) and would help https://source.puri.sm/Librem5/squeekboard/-/issues/281 since the same popover could indicate the alternate key before releasing.
See https://fosstodon.org/@postmarketOS/105397265991389371 how this looks in osk-sdl.https://source.puri.sm/Librem5/squeekboard/-/issues/281Have alternate characters via swipe down2021-05-06T12:28:47ZGuido GuntherHave alternate characters via swipe downSome OSKs allow to press+hold and swipe down a button to get another symbol. this makes accessing more symbols easier and way quicker. Would be great to have this too, might conflict with https://source.puri.sm/Librem5/squeekboard/-/issu...Some OSKs allow to press+hold and swipe down a button to get another symbol. this makes accessing more symbols easier and way quicker. Would be great to have this too, might conflict with https://source.puri.sm/Librem5/squeekboard/-/issues/93 but would improve my typing speed considerably.https://source.puri.sm/Librem5/squeekboard/-/issues/280Asking squeekboard it's version causes a: Trace/breakpoint trap (core dumped)2021-04-19T13:43:41ZJoao AzevedoAsking squeekboard it's version causes a: Trace/breakpoint trap (core dumped)
```
purism@pureos:~$ squeekboard --version
Debug: Tried file "/home/purism/.local/share/squeekboard/keyboards/us.yaml", but it's missing: No such file or directory (os error 2)
Info: Loaded layout Resource: us
Debug: Tried file "/home/...
```
purism@pureos:~$ squeekboard --version
Debug: Tried file "/home/purism/.local/share/squeekboard/keyboards/us.yaml", but it's missing: No such file or directory (os error 2)
Info: Loaded layout Resource: us
Debug: Tried file "/home/purism/.local/share/squeekboard/keyboards/us.yaml", but it's missing: No such file or directory (os error 2)
Info: Loaded layout Resource: us
** (squeekboard:2855): ERROR **: 13:06:03.665: DBus unavailable, unclear how to continue.
Trace/breakpoint trap (core dumped)
```
And no the files: `/home/purism/.local/share/squeekboard/keyboards/us.yaml` are not present in my system but `squeekboard` says my default is English.
This is on PureOS Byzantium latest version, but upgraded from Amber.https://source.puri.sm/Librem5/squeekboard/-/issues/279less lines in wide mode2021-05-08T19:26:52ZAntonis Tsolomitisless lines in wide modeOn L5 when in wide mode the keyboard takes up most of the vertical space because it still has 4 lines although there is plenty of horizontal space. Could it be possible and useful to change the layout so that only in landscape mode the k...On L5 when in wide mode the keyboard takes up most of the vertical space because it still has 4 lines although there is plenty of horizontal space. Could it be possible and useful to change the layout so that only in landscape mode the keyboard is layed in 2 rows instead of 4?https://source.puri.sm/Librem5/squeekboard/-/issues/278Allow font selection for the glyphs that appear on the keyboard2021-05-11T00:28:04ZAntonis TsolomitisAllow font selection for the glyphs that appear on the keyboardCurrently squeekboard does not respect the desktop selection of fonts (text font, mono font or other) but uses a font the user can not change. For example when in Greek it uses the Sans font although the user has selected other fonts for...Currently squeekboard does not respect the desktop selection of fonts (text font, mono font or other) but uses a font the user can not change. For example when in Greek it uses the Sans font although the user has selected other fonts for the desktop (using gnome-tweak).https://source.puri.sm/Librem5/squeekboard/-/issues/275Please consider using `GtkApplication`2021-03-25T15:17:45ZGuido GuntherPlease consider using `GtkApplication`Using `GtkApplication` would have avoided #274 and als makes the DBus code simpler, it also gives a place to stuff the 'globals' which are in use server-main.c (and a lot of them would become obsolete).Using `GtkApplication` would have avoided #274 and als makes the DBus code simpler, it also gives a place to stuff the 'globals' which are in use server-main.c (and a lot of them would become obsolete).https://source.puri.sm/Librem5/squeekboard/-/issues/273Plese use async dbus calls to register to the session in session_register2021-03-25T12:05:54ZGuido GuntherPlese use async dbus calls to register to the session in session_registersync calls can block.sync calls can block.https://source.puri.sm/Librem5/squeekboard/-/issues/268Squeekboard is shown on Lockscreen2021-07-07T06:42:38Zarno nuehmSqueekboard is shown on LockscreenHello there and thanks for your great work on Phosh and Squeekboard. Really enjoying it on my PinePhone.
# What problem did you encounter
Squeekboard stays openend on the lock screen after locking the phone.
## What is the current beha...Hello there and thanks for your great work on Phosh and Squeekboard. Really enjoying it on my PinePhone.
# What problem did you encounter
Squeekboard stays openend on the lock screen after locking the phone.
## What is the current behaviour?
While searching an app in the search bar and after locking the phone, Squeekboard is not closed and stays visible on the lock screen.
## What is the expected behaviour?
Squeekboard gets closed after pressing the power button / locking the phone.
## How to reproduce
* Tap into the App Menu Search Bar --> Squeekboard opens
* Press the power button once --> phone is locked + black screen (if activated)
* Press the power button again --> lock screen appears + opened squeekboard is still there
# Which version did you encounter the bug in?
```
Phosh Version: 0.8.1-1mobian1
```
![screenshot](/uploads/4bda1c58a56fe8762747a36d8b0b206b/screenshot.png)
# What hardware are you running phosh on?
PinePhonehttps://source.puri.sm/Librem5/squeekboard/-/issues/267Crash in on_notify_keyboard2021-04-01T14:29:49ZSebastian KrzyszkowiakCrash in on_notify_keyboardI don't have much more to comment about this crash other than providing the backtrace - it just occurred randomly while using the phone.
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x0000ffff8c50b8e...I don't have much more to comment about this crash other than providing the backtrace - it just occurred randomly while using the phone.
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x0000ffff8c50b8e8 in __GI_abort () at abort.c:79
#2 0x0000ffff8c557718 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0xffff8c617728 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x0000ffff8c55dcdc in malloc_printerr (str=str@entry=0xffff8c6131c0 "double free or corruption (out)") at malloc.c:5359
#4 0x0000ffff8c55f8a8 in _int_free (av=0xffff8c657a98 <main_arena>, p=0xaaaadd0da550, have_lock=<optimized out>) at malloc.c:4321
#5 0x0000aaaabf6f00f4 in on_notify_keyboard (object=<optimized out>, spec=<optimized out>, self=0xaaaadd06f140) at ../eek/eek-gtk-keyboard.c:378
#6 0x0000ffff8d3e69f8 in g_closure_invoke (closure=0xaaaadcfa3120, return_value=0x0, n_param_values=2, param_values=0xfffffb576470, invocation_hint=0xfffffb576438) at ../../../gobject/gclosure.c:810
#7 0x0000ffff8d3fb2b8 in signal_emit_unlocked_R (node=node@entry=0xaaaadcf4acb0, detail=1216, detail@entry=0, instance=0xaaaadd0cfdc0, instance@entry=0x0, emission_return=emission_return@entry=0x0,
instance_and_params=0xfffffb576470, instance_and_params@entry=0x41576e5f2d70616d) at ../../../gobject/gsignal.c:3635
#8 0x0000ffff8d40362c in g_signal_emit_valist (instance=instance@entry=0xaaaadd0cfdc0, signal_id=signal_id@entry=1, detail=<optimized out>, var_args=...) at ../../../gobject/gsignal.c:3391
#9 0x0000ffff8d403b98 in g_signal_emit (instance=instance@entry=0xaaaadd0cfdc0, signal_id=signal_id@entry=1, detail=<optimized out>) at ../../../gobject/gsignal.c:3447
#10 0x0000ffff8d3eb808 in g_object_dispatch_properties_changed (object=0xaaaadd0cfdc0, n_pspecs=<optimized out>, pspecs=<optimized out>) at ../../../gobject/gobject.c:1088
#11 0x0000ffff8d3edf10 in g_object_notify_by_spec_internal (pspec=<optimized out>, object=0xaaaadd0cfdc0) at ../../../gobject/gobject.c:1181
#12 g_object_notify (object=0xaaaadd0cfdc0, property_name=property_name@entry=0xaaaac0f99f78 "keyboard") at ../../../gobject/gobject.c:1229
#13 0x0000aaaabf6f2d38 in eekboard_context_service_use_layout (context=0xaaaadd0cfdc0, state=<optimized out>, timestamp=0) at ../eekboard/eekboard-context-service.c:166
#14 0x0000aaaabf6f065c in eek_gtk_keyboard_real_size_allocate (self=0xaaaadd06f400, allocation=0xfffffb576928) at ../eek/eek-gtk-keyboard.c:129
#15 0x0000ffff8ce12080 in gtk_widget_size_allocate_with_baseline (widget=widget@entry=0xaaaadd06f400, allocation=allocation@entry=0xfffffb576998, baseline=<optimized out>, baseline@entry=-1)
at ../../../../gtk/gtkwidget.c:6175
#16 0x0000ffff8ce123e8 in gtk_widget_size_allocate (widget=widget@entry=0xaaaadd06f400, allocation=allocation@entry=0xfffffb576998) at ../../../../gtk/gtkwidget.c:6256
#17 0x0000ffff8ce29384 in gtk_window_size_allocate (widget=0xaaaadd238740, allocation=<optimized out>) at ../../../../gtk/gtkwindow.c:7932
#18 0x0000ffff8d3e69f8 in g_closure_invoke (closure=0xaaaadcfa9e00, return_value=0x0, n_param_values=2, param_values=0xfffffb576ba0, invocation_hint=0xfffffb576b68) at ../../../gobject/gclosure.c:810
#19 0x0000ffff8d3faa58 in signal_emit_unlocked_R (node=node@entry=0xaaaadcfa5030, detail=detail@entry=0, instance=0xaaaadd238740, instance@entry=0x0, emission_return=emission_return@entry=0x0,
instance_and_params=0xfffffb576ba0, instance_and_params@entry=0x0) at ../../../gobject/gsignal.c:3565
#20 0x0000ffff8d40362c in g_signal_emit_valist (instance=instance@entry=0xaaaadd238740, signal_id=<optimized out>, detail=detail@entry=0, var_args=...) at ../../../gobject/gsignal.c:3391
#21 0x0000ffff8d403b98 in g_signal_emit (instance=instance@entry=0xaaaadd238740, signal_id=<optimized out>, detail=detail@entry=0) at ../../../gobject/gsignal.c:3447
#22 0x0000ffff8ce12348 in gtk_widget_size_allocate_with_baseline (widget=widget@entry=0xaaaadd238740, allocation=allocation@entry=0xfffffb577020, baseline=<optimized out>, baseline@entry=-1)
at ../../../../gtk/gtkwidget.c:6173
#23 0x0000ffff8ce123e8 in gtk_widget_size_allocate (widget=widget@entry=0xaaaadd238740, allocation=allocation@entry=0xfffffb577020) at ../../../../gtk/gtkwidget.c:6256
#24 0x0000ffff8ce29cd4 in gtk_window_move_resize (window=0xaaaadd238740) at ../../../../gtk/gtkwindow.c:10027
#25 0x0000ffff8d3e4eec in g_type_class_meta_marshalv (closure=<optimized out>, return_value=<optimized out>, instance=<optimized out>, args=<error reading variable: Cannot access memory at address 0x8>,
marshal_data=<optimized out>, n_params=<optimized out>, param_types=<optimized out>) at ../../../gobject/gclosure.c:1030
#26 0x0000ffff8d3e6c5c in _g_closure_invoke_va (closure=0xaaaadcfaa6a0, return_value=0x0, instance=0xaaaadd238740, args=<error reading variable: Cannot access memory at address 0x8>, n_params=0,
param_types=0x0) at ../../../gobject/gclosure.c:873
#27 0x0000ffff8d403690 in g_signal_emit_valist (instance=0xffff8d43a000, signal_id=<optimized out>, detail=0, var_args=...) at ../../../gobject/gsignal.c:3300
#28 0x0000ffff8d403b98 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../../../gobject/gsignal.c:3447
#29 0x0000ffff8cbded3c in gtk_container_idle_sizer (clock=0xaaaadcfc25d0, container=0xaaaadd238740) at ../../../../gtk/gtkcontainer.c:2065
#30 0x0000ffff8d3e6c5c in _g_closure_invoke_va (closure=0xaaaadd1c2f40, return_value=0x0, instance=0xaaaadcfc25d0, args=<error reading variable: Cannot access memory at address 0x8>, n_params=0,
param_types=0x0) at ../../../gobject/gclosure.c:873
#31 0x0000ffff8d403690 in g_signal_emit_valist (instance=0xffff74010980, instance@entry=0xaaaadcfc25d0, signal_id=<optimized out>, detail=2080388336, detail@entry=0, var_args=...)
at ../../../gobject/gsignal.c:3300
#32 0x0000ffff8d403b98 in g_signal_emit (instance=instance@entry=0xaaaadcfc25d0, signal_id=<optimized out>, detail=detail@entry=0) at ../../../gobject/gsignal.c:3447
#33 0x0000ffff8c992020 in _gdk_frame_clock_emit_layout (frame_clock=frame_clock@entry=0xaaaadcfc25d0) at ../../../../gdk/gdkframeclock.c:651
#34 0x0000ffff8c992ba8 in gdk_frame_clock_paint_idle (data=0xaaaadcfc25d0) at ../../../../gdk/gdkframeclockidle.c:575
#35 0x0000ffff8c97b858 in gdk_threads_dispatch (data=0xaaaadd0e1140, data@entry=<error reading variable: value has been optimized out>) at ../../../../gdk/gdk.c:769
#36 0x0000ffff8d2f30e4 in g_timeout_dispatch (source=0xaaaadd1b3940, callback=<optimized out>, user_data=<optimized out>) at ../../../glib/gmain.c:4667
#37 0x0000ffff8d2f251c in g_main_dispatch (context=0xaaaadcf6b820) at ../../../glib/gmain.c:3182
#38 g_main_context_dispatch (context=context@entry=0xaaaadcf6b820) at ../../../glib/gmain.c:3847
#39 0x0000ffff8d2f28e8 in g_main_context_iterate (context=0xaaaadcf6b820, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../glib/gmain.c:3920
#40 0x0000ffff8d2f2c80 in g_main_loop_run (loop=0xaaaadd044200) at ../../../glib/gmain.c:4116
#41 0x0000aaaabf6ee644 in main (argc=<optimized out>, argv=<optimized out>) at ../src/server-main.c:309
```https://source.puri.sm/Librem5/squeekboard/-/issues/264Add copy/paste buttons2021-04-01T14:30:17ZGuido GuntherAdd copy/paste buttonsOther OSes have it and it helps a lot when one doesn't have to navigate to ctrl-c/ctrl-v (also terminal is not always available e.g. when numeric is active).
This likely overlaps with other issues so please ressign if there's a good fit.Other OSes have it and it helps a lot when one doesn't have to navigate to ctrl-c/ctrl-v (also terminal is not always available e.g. when numeric is active).
This likely overlaps with other issues so please ressign if there's a good fit.https://source.puri.sm/Librem5/squeekboard/-/issues/263Feature request/Developer comment: Will future versions of sqeekboard/phosh i...2021-01-22T17:17:07ZTristan VFeature request/Developer comment: Will future versions of sqeekboard/phosh include typing accessibility features? Larger keys on press, etc.I'm unsure if this is a Phosh, GTK or Squeekboard question.
When typing on most mobile phone keyboards, a small window showing the key you are pressing will show above the key as a way to provide visual confirmation of the key you press...I'm unsure if this is a Phosh, GTK or Squeekboard question.
When typing on most mobile phone keyboards, a small window showing the key you are pressing will show above the key as a way to provide visual confirmation of the key you press. In Phosh's current state, you need to very deliberately type and aside from the small parts of a key that are highlighted (that aren't obscured by your fingers), the only way to tell if you pressed the right key is looking at the active context box after typing. Is this planned for future revisions or is this currently in the works? Is there a discussion about this happening somewhere else? Any information you can provide would be greatly appreciated!https://source.puri.sm/Librem5/squeekboard/-/issues/261Alternative layouts currently broken2021-04-01T14:21:12ZNathan VanceAlternative layouts currently brokenThe Region & Language Input Sources tool makes available the same list of layouts which are available on a standard Linux installation. When selecting layouts for different languages, the keyboard behaves as expected. However, when selec...The Region & Language Input Sources tool makes available the same list of layouts which are available on a standard Linux installation. When selecting layouts for different languages, the keyboard behaves as expected. However, when selecting alternative layouts for a language such as English (Dvorak) or English (Colemak), the layout becomes the same as English (US), which is incorrect.https://source.puri.sm/Librem5/squeekboard/-/issues/259Not sending CTRL/ALT/Shift key events (and just setting the modifiers) breaks...2021-02-07T20:51:38ZellieNot sending CTRL/ALT/Shift key events (and just setting the modifiers) breaks some applicationsNot sending CTRL/ALT/Shift key events and just setting the modifiers breaks some applications. The problem isn't just games that may require these keys to be pressed on their own, but also that some UI applications may track modifiers ma...Not sending CTRL/ALT/Shift key events and just setting the modifiers breaks some applications. The problem isn't just games that may require these keys to be pressed on their own, but also that some UI applications may track modifiers manually by listening for these key inputs instead. E.g. I use an SDL2 non-game app that does that.
Therefore I suggest that CTRL + ALT events should be toggled along with the buttons being toggled in squeekboard's terminal layout, and a left shift key down event should be sent as soon as a key is typed from the uppercase pane after one from a different pane and key up when vice versa (such that the mere act of toggling through the panes doesn't generate key presses on its own, since I think most users would not expect that).https://source.puri.sm/Librem5/squeekboard/-/issues/255Dropped text-input events when receiving application hangs for a moment2020-12-12T14:32:10ZSebastian KrzyszkowiakDropped text-input events when receiving application hangs for a moment(this might be a compositor, toolkit or even protocol issue, but filling it here as a starting point for investigation)
When a text-input-using application hangs for a moment, further key strokes made in squeekboard are dropped instead ...(this might be a compositor, toolkit or even protocol issue, but filling it here as a starting point for investigation)
When a text-input-using application hangs for a moment, further key strokes made in squeekboard are dropped instead of being buffered and delivered/handled once the app gets back to its event loop (unlike virtual-keyboard keystrokes, which are all eventually processed correctly).
The most visible examples of that are phosh search bar when it's filled with plenty of applications, or browser address bar when it's busy rendering a heavy page.
So far I've seen it only with gtk apps, but haven't really looked very hard to confirm whether it happens with other toolkits too or not. A gtk app with text entry that reacts to incoming text with sleeping for a second should be a good reproducer.https://source.puri.sm/Librem5/squeekboard/-/issues/254Handle "docked mode" as expected2021-05-20T08:26:41ZDorota CzaplejewiczHandle "docked mode" as expected"Docked mode" doesn't adequately cover what this is about, but at this point it's the most descriptive.
This is about the interaction of various OS components, in order to give the user some input it expects. Part of this issue is to de..."Docked mode" doesn't adequately cover what this is about, but at this point it's the most descriptive.
This is about the interaction of various OS components, in order to give the user some input it expects. Part of this issue is to define what the user would expect.
Physical and virtual keyboards
------------------------------
In "docked mode", we define user's interaction with the L5 as if it was a laptop. That means a full physical keyboard.
In this case, the input method should mostly keep its general input panel(s) hidden, because they would be redundant. That includes not showing them when application requests an input method.
In phone mode, the on-screen keyboard may be the only way to input text, so it should be automatically shown, and in case of legacy programs, the user should have a way to bring it (e.g. via shell button).
### Details
What we really care about is redundancy, so a physical numpad-only does not collide with a qwerty on-screen keyboard. So in this setup, for the purpose of text fields, we're "phone", and for the purpose of number fields we're "docked".
In several cases, users might find the on-screen panel more useful than physical:
- handwriting
- button labels adjusting according to what's written (upper/lower case, whatever it is called that's like ligatures)
- mismatched labels on the physical keyboard (emoji is in this category)
- more buttons available
Consumers
---------
Docked mode should be communicated at least to the input method (to let it stay hidden), and to the shell (to show the keyboard override button, and to show keyboard indicator).
The compositor needn't know. While it sounds tempting to disable text-input protocol, this is moot because of for example non-Latin inputs.
Policy
------
From Details section, there are two kinds of policy sources:
- user preferences
- comparing the physical and on-screen input abilities for redundancy (taking script into account)
User preferences can be communicated to any of the input method, shell, or compositor, and relayed easily.
The physical input capabilities are fully known by the compositor, but can be relatively accurately relayed anywhere. `wl_keyboard` already partially serves that and is builtin.
However, only the input method knows exactly what capabilities it has, due to the free-form nature of the medium. This makes the input method the ideal place for determining whether input panels should be visible.
Implementation
--------------
To turn the input method into the policy place, there need to be ways of communicating a bunch of things:
- initially the number, and later the capabilities of physical keyboards from the compositor to the input method (probably Wayland protocol)
- whether the input panel is redundant - the input method tells the shell (probably d-bus, although ideally it would respect Wayland seats)
Caveat: to be 100% sure about redundancy, we need to always know that the keyboard is full (I believe keyboards don't advertise if they have a numpad), and failing that, always know the text field type (we don't, text-input is not universal). So it's reasonable to give the user a way to being up the on-screen panel anyway even in docked mode. (if we insist on making the override button disappear, a gsetting maybe?).https://source.puri.sm/Librem5/squeekboard/-/issues/252Support key combos from a single virtual key2020-11-25T11:09:28ZFredSupport key combos from a single virtual keyWould be very handy to be able to map a key combo to a single key - examples:
<kbd>Ctrl</kbd>-<kbd>F</kbd> - Find.
<kbd>Ctrl</kbd>-<kbd>x|c|v</kbd> - cut/copy/paste.
<kbd>Ctrl</kbd>-<kbd>;</kbd> - Open GNOME's emoji picker (saves having...Would be very handy to be able to map a key combo to a single key - examples:
<kbd>Ctrl</kbd>-<kbd>F</kbd> - Find.
<kbd>Ctrl</kbd>-<kbd>x|c|v</kbd> - cut/copy/paste.
<kbd>Ctrl</kbd>-<kbd>;</kbd> - Open GNOME's emoji picker (saves having to switch layouts to enter an emoji).