Squeekboard set default layout to terminal


I have been looking up the forum and squeekboard git repo to find out if it is possible to set the default layout to terminal on squeekboard?

Is it currently possible?


shameless bump?

1 Like

There’s no “default” layout. It always corresponds to the keyboard layout you selected, except if it’s unsupported. Then it falls back to “us”. For info how to replace builtin layouts with your preferred ones, check out the tutorial, especially the testing section: https://developer.puri.sm/projects/squeekboard/tutorial.html#testing-the-layout


I see so no way to get the “terminal” layout as default.

It always ( after reboot/shutdown, and even sometimes between terminal uses/close/start ) fallback to US for me, it never stay set to Terminal


Okay I see, so it is a result of me setting up the input sources to French (Canada).

To test I switched to English (Canada) then I copied the terminal.yaml layout to .local/data/squeekboard/keyboars/ca+eng.yaml

Now I see the English (Canada) in squeekboard Globe Icon.

Lets see if it stay there :wink:

Yes this survive a reboot.

1 Like

If you use a layout that’s not supported (like French+Canada), then it’s going to try whatever name GNOME assigns to it (check the logs, probably something like ca+fr?).

BTW, if you find your layout is not directly supported - I know for sure we neither have a builtin “ca+eng” nor plain “ca”, then we welcome contributions. You can even copy/symlink an existing layout: the point of that is to have an actual user confirm that such a layour makes sense.

I do a lot of typing into a bash terminal & (like @purismforum) I find I need quick access to the Ctrl mode, the up arrow, escape, etc. However, I prefer a Dvorak layout to Qwerty.

For the moment I’m test driving a freshly coded “us+dvorak-terminal” layout by naming it us+dvorak-alt-intl.yaml (with a wide variant too), but I’m trying to come up with a way to cleanly integrate the functionality. I can imagine someone wanting a Spanish Terminal, French Terminal, etc.

It’s almost like “terminal” should be a mode (a bit similar to “wide”), with it summoned via a checkbox on the layout menu rather than a distinct layout as it is now. (Similar to how undefined layouts fall back to “us”, if terminal mode is requested but not defined, it would fall back to the current us terminal.) I’m happy to take a whack at the coding if this design sounds reasonable.


I agree to that. For me the terminal features is a must, those arrows, esc, ctrl/alt. I am using vim so there is no escaping this.

And ctrl-c is a total must for terminal anyway :slight_smile:

We had some early discussions about that exact aspect, but since no one actually needed that or implemented anything, we didn’t settle on anything.

Do you think there’s any merit in automatically generating the terminal layouts from the base layouts, or rather that it should always be a separate job?

Is a total must in most apps that have any text. Also +v, +a, +f and +z.
I second/third/Nth the idea because even in terminal you need the specials of your languages basic layout - and goes against muscle memory to have that change when entering terminal.

1 Like

Automatic generation sure seems appealing. Most current users are geeky enough to often need terminal functionality, but you want to make hiding that stuff an option for future non-techies like spouses (or, i hope, the general masses). Seems it would be easy if the “terminal” checkbox is enabled, then 1) squish the keys a bit vertically to make room for the Ctrl/Alt row at the top, and 2) shrink the space key to make room for a show_actions button. (My initial inclination was to convert an period/fullstop in the bottom row to show_actions, but some layouts - like fr - don’t have a period there. Maybe do a space squish only if period conversion isn’t possible.) I haven’t yet surveyed all existing layouts to see if that’s realistic.

And not to forget what kicked this thread off, the terminal checkbox should be sticky between boots.

Holler if you want me to give the coding a shot. Anytime I see “phone developer” in someone’s title, I’m hoping they could instead be working on idle battery life improvements rather than minor stuff like this. :slight_smile:


That goes without saying.

When I read that you mention some significant variance between punctuation, I started thinking maybe just a simple separate layout is sufficient for now.

I’m currently wrestling the camera, sorry :stuck_out_tongue:


No worries, putting your time on camera is worth more money to Puri.sm than the keyboard.

Once puri.sm get all the camera users in there, the budgets will get up, and polishing can happen for those more tech savvy users.

Thinking more about it.

Having the terminal variation for software requiring it could also be a good thing.

Example the console would require the terminal variant, but the browser can keep the default.

Even a “web” variant to have those / @ . could be handy with browser. Not sure if the keyboard knows what is pulling it ( aka oh browser want a keyboard lets give it the web variant ).

The terminal can do it already. It doesn’t. And it’s understandable, the terminal library (vte) is very broken in terms of text input, so it may never happen.

1 Like

See https://source.puri.sm/Librem5/squeekboard/-/issues/233

Here is my take over it https://git.qoto.org/m33/kbdupdater

1 Like