OK, that was a learning experience. No obvious way to do a screen shot, so I searched and discovered a command line tool named grim; that and a sleep command let me do what I wanted…except that in landscape mode grim inverts the picture (regardless of which way I turn the phone into landscape). So after transferring it to my desktop, I got to run gimp to rotate the pictures 180 degrees.
Anyhow…Here is the base view, and uppercase view, in portrait mode.
That looks really nice! I love the wide mode layout the best, it’s basically a full keyboard.
You’ll have to report back on your typing accuracy. I have trouble hitting the correct keys on the default keyboard as it is. Typing long passwords is a chore, especially if you get it wrong a few times.
My L5 comes with a screenshot package that I used for my post. I’m not sure of the name to install. Maybe it comes in librem5-goodies? I’m not sure.
I just squeezed a 12 pixel tall “dummy” invisible spacer under the space bar on the portrait mode; I decreased the height of the two short rows by two pixels each to make some space for it. I basically did that so a near miss on the space bar wouldn’t send whatever app I was in to whatever they call that place where they’re loaded but not active. THAT is frustrating when it happens, you hit spacebar and your app zooms away…
Thanks to a prior comment of yours for giving me the clue. I went looking for librem5-goodies, which does indeed have the screen shot in it. It’s based on grim, though, and still takes the pictures in landscape mode upside down, just like my command line hack (sleep 5; grim [filename]). (I also found it unintuitive to use the screen shot…where’s the “OK this is fine, now start the timer” button? I don’t know what I actually did to trigger it, but by the time I realized the five seconds were counting down, it was too late to show the keyboard.
Besides Take Screenshot (part of librem5-goodies), there is also GNOME Screen Shot, which has slightly different controls, including a manual Save button instead of just the countdown to autosave. (Neither of them should invert your landscape keyboard, though…not sure what’s happening there.)
grim doesn’t just invert the keyboard, it inverts (rotates 180) the entire image. And the distributed file viewer doesn’t have a button to rotate the image and save it (like Microshaft’s does).
Has anyone else used grim (or Take Screenshot) and NOT had it rotate the image?
@dcz, do you know the exact pixel dimensions of the keyboard area in both portrait and landscape? (I’m aware that whatever you create will be shrunk/expanded to fit with it “letterboxed” top and bottom left or right if the layout aspect ratio isn’t the same as the area; but I’d rather use the area than waste it so I’d want my layout to have the same proportions.)
Oh wow, it does. I never observed that before. I did have issues with landscape mode in Millipixels, though, with the image rotating 90 degrees to the right when I wanted to take a photo in landscape mode. Turns out I just should have turned the camera sideways without having screen rotation turned on. That’s a different issue, though.
Thanks for the pointers to that documentation; I had never seen it before. (There’s a page often pointed to on the wiki which is very incomplete and doesn’t even talk about the hints; it was enough to get me started but my knowledge had gaps in it.)
540x310 Landscape? Did you mean portrait (vertical)?
From what I saw the actual screen dimensions of a librem are 1440 x 720 pixels, so the portrait keyboard is 720 wide by some unknown number tall in actual pixels. If the ratio you gave is correct, the vertical pixel height should be 413 1/3. I learned pretty quickly (and the docs say) that whatever size in units your keyboard totals out to, it will be expanded or shrunk to fit in whatever rectangle Squeekboard uses. I tried simply adding another row, expecting the keyboard to cover more of the screen to accommodate it, instead the entire keyboard shrank to fit the 413 (?) pixels, and it was now too narrow with black areas on either side. Conversely removing rows so the keyboard covers less of the screen (which would be useful in landscape mode!) just makes the keys larger. In general, if your keyboard is relatively wide compared to its height, you get “letterboxing” above and below it (like watching a 16:9 movie on a 4:3 TV [if any of those even exist any more!], if it’s too narrow, you get black on the sides like watching an old 4:3 DVD on a 16:9 TV.
I was after the aspect ratio of the area both in portrait and landscape; now I know the ratio is 54:31 in portrait mode (but still don’t know landscape). My portrait layout is 528 units wide (16x33, and the default key is 48 units wide, so there can be 11 of them across; the spacers I use for the staggered effect are 16 and 32 units wide)
I really wish it were possible to change the aspect ratio (ideally the app would compute it from the file and only take up the appropriate vertical real estate), especially in landscape mode, where the current app consumes over half the screen. A wide format should be, maybe, 20 keys across and two keys high, and cover much less of the screen.
Anyway, now that I know the portrait mode aspect ratio, I can go back to my layout and ensure it’s 528 x 303 (by adjusting the height of the keys) to maximize usage of the area. That’s as close as I can get to matching 54:31.
Thanks! Will get some good use out of that. Looks like, reduced, it’s 12:7 portrait, and 135:43 landscape…my portait mode keyboard should be 528x308 units. (I actually didn’t total up the landscape one at all, now I can do so intelligently.)
I have been using those layouts (and I tinkered with them a bit more yesterday, consolidating styles and fixing things so that I don’t have to define a whole bunch of additional “dark key” styles like altline in the CSS page (CSS is where you alter colors)).
Basically, I named these styles us.yaml, us_wide.yaml, and so on, so they’d replace the “hard coded” styles.
I have no idea where an appropriate place would be to upload them, nor whether I need to rename them somehow.
The latter set 172 x 540, doesn’t seem right…my landscape layout is clearly at least 4 times as wide as it is tall (see my screen shots) and seems to fill the panel almost perfectly (it should be a bit wider). Is it possible something else (other than the code you excerpted) affects it?
Well, it’s the minimal proportion. Anything flatter than that will also use the wide layout, adjusted to this particular display. The limitation in play here is the number of rows: buttons won’t shrink to be too small to press.
There are many ways to share files, but I was thinking more in the line of sharing them here.
I have no idea what the total size will be of the layouts you have made.
Maybe Purism can jump on board and offer a solution.
OK, I suppose I can paste them into a comment. There will be three files.
There are a couple of things I want to debug first…I modified the function keys layout some and introduced an issue there, and also I discoved my dummy spacer keys register a keypress if you hit them accidentally (no key ends up in your file, but if you did a latch shift (the kind that only holds for the next character), and hit one of these by mistake, it’s enough to do an “un-shift”.
Again, these are set up to replace the us keyboard. I’ll explain that when I upload them.
