The precise of the courser is a main issue, that’s right. That currently installed lens is also helping a lot to hit the point I want to. But I also use Shift + arrows on my PC from time to time, even without precise issues simply because it’s comfortable to use.
I have no idea what Android and iOS does since my smartphone before L5 was from 2012 or 2013 and just used it for SMS, calls and some simple photos. The usage is already totally different after using L5 2 weeks and I guess it would be also compared to a modern Android, because L5 is no smartphone and this way I also was thinking that Squeekboard should be able to do more than an Android keyboard UI.
Zooming every application where I could want to copy some text etc could be helpful. Text editor cannot handle this right now. But that would also not be a nice workflow since you have to zoom in and zoom out and zoom in and sometimes you want to mark longer texts. Not to say that it would take a huge amount of work to apply this change to every app. It’s also a little mess, even if marking could work better. I have no other idea right now.
What you’re describing is a GTK bug. Selecting text really sucks, and I actually agree because I had to do it 15 minutes ago, and I had to do like 10 attempts to select the first line in a text file, and when I figured it out, it still required too much manual precision. Other people are going to have this problem too. Do we expect all people with the problem to know that they should load a special input method to handle this? I don’t. This should be solved for everyone, and super secret workarounds are not enough.
I suggest reaching out to GTK and complaining about how text selection works.
Maybe the solution involves the input method, but it definitely does not involve emulating presses of switches on a keyboard.
I finished my advanced German terminal layout, but colors are still placeholder (have to think about a nice composition). It’s optimized for 150% screen scale. The @-layer contains also all additional France letters. The widescreen Squeekboard also contains some more characters, especially on shifted math layout. The small keys on the left are easy and precise to reach when sliding fingers from the side into the screen.
The last 2 layouts are orientated to the Neo keyboard. Also was thinking about doing same on main layers, but that could be very confusing and the benefits of Neo is more on physical layouts.
Do I miss something important or should I change anything?
@dcz (edit: sry pinged wrong person):
Do you have any specific requirements for up-streaming keyboards? At least I may want to create a default German terminal keyboard (orientated to us.yaml from repository). I think modifier are not allowed for non terminals. But what is about custom gtk.css requirement? Some characters need specific size, the black spacer are also just non functional buttons and or just for letting people modify colors easily.
I don’t like the idea of custom css for keyboards because it makes the meanings of buttons inconsistent between layouts unless we enforce lots of rules, and I don’t have the time or expertise for that. But if the design team says it’s a good idea, I’ll follow that.
Black spacers need a css-free fix on the squeekboard side, so don’t worry about it.
Layouts specific to a certain script must not contain letters which do not appear in the script. Different people will want different extra letters, and I don’t want maintainers to become arbiters of language usage. Add symbols if you want to fill unused space.
Has anyone considered, or has been working on a gamepad version of squeekboard? It would be useful for some native desktop games like SuperTux, Minetest, but also for emulators.
Some potential issues:
In some games (and apps for that matter too) input from squeekboard is not recognized (e.g. Sonic Robo Blast 2 Kart, YouTube Music Desktop). For apps at least, there is a workaround for Ctrl + C/X/V… working, and both still work with an external keyboard
For analog stick input, I am not familiar enough myself with how this type of input is mapped. The best I’d be able to do on my own is a PS Classic style controller.
For landscape mode, it would probably be best for small screens to split the keyboard in half, to be on either side of the screen for each hand, similar to the black bars that appear on 4:3 content on a 16:9 display
If PureOS switches to an all gesture based UI as I imagine the direction is trending towards, then the keyboard would need a method to show the gamepad for specific applications, else the keyboard only would come up when it detects a text box is in focus
Layout: not sure if it is best to map & visually display buttons to that similar that one would use to game (e.g. ASDF), or for how they typically are (e.g. ABXY). Select & Start could be backspace and enter, or space and ESC, or maybe all 4 are provided in that area. Would want to balance intuitiveness, minimizing workflow changes, and maximizing compatibility with all controller types into one pad
This thread is more about editing layers and not about modify Squeekboard entirely. And some of your wishes are things that I think will never be supported with Squeekboard and need a totally different solution. Squeekbaord has predefined keys an cannot simulate everything. This may gets better if shortcuts would be implemented (this way we could implement up + left arrow to diagonal up-left arrow or even up-up-left).
Best thing would be if games support it by themselves. An additional keyboard is just a poor fix for unsupported inputs. However, in some cases it makes sense.
@ 5.) I created a new thread for that specific topic. Even if it could be handled in this thread, it’s better to make an own, because it’s for a very specific layout that will need a lot of work.
Very nice and posts. I have done the same with the default keyboard layout not quite being enough for me.
Here’s what I’ve got so far. It’s a bit more of a normal keyboard, with the symbol layer customised for writing Te Reo Māori (the New Zealand Native Language) and including symbols I use often. The keys are definitely on the small size, but seem to be big enough to minimise errors. I also made layouts for the Workman layout Workman-P in terminal as I have been wanting to switch to the layout for ages and figure this would be a good way to do it.
Todos:
fix the colouring on the keys (missing the return blue)
I worked on default terminal for Germany. I want to upstream it one day, but the whole process looks so complicated (never did a MR before nor compiled something from git) and I have not much time to learn it actually. However, for people who want the file right now, here it is:
@dos:
I run again into the issue where Modifiers get reset and tried to look deeper into the issue. So I found your bug report one day after you reported it - luckily was not looking before. That 8 bit border makes totally sense to me. But modifiers are not totally broken - if I copy a text and want to paste with Ctrl + v, I will write first time v and if I repeat it, it will paste what I copied. I’m just not allowed to do something else in between (like pushing backspace to remove the written V letter). That also works with nearly every other modifier and combination (except such as Ctrl+x, because marked text becomes letter x and so nothing to copy anymore).
Hopefully it get fixed soon, because my widescreen and terminal keyboard are modifier broken right now.
The cool thing with Squeekboard → we can add special use case keyboards. It speeds up things a lot. The padding-button typed padding: ;, so I just need to fill the values. I made this post to show you alternative ways to use Squeekboard.
Initial Release of my custom layout is here. As you can see above, it is a German layout, but you can customize it. If you want, I will also add your customized languages, but only if they match this style more or less. Here is a screenshot of the current state.
There is a file for 100%/200% screen scale, but also for 125%, 150% and 175%. I did the math that they fit perfectly into portrait view and wont support other scales. Landscape needs an update before releasing it.
You also can decide between the color version you see above, but you also can use a color version that matches the default Squeekboard color. Currently I just have one color-theme. If you have any wishes, I will create some more (or upload your creations).
For default color you can decide if you want a css-fix for font size etc or if you stay default without any css-file. It may looks less good, but it should be usable in any case.
Also, if you find any bugs, please let me know (in best case with screenshot).
Installation etc is described on README-file. There is only a manual installation right now and I have not much experience in creating scripts yet. I’m not sure if or when I will create such. So if someone wants to create it (@Emma? *asking kindly*), I would be happy.
I’m a bit confused. When I log-out I also have no access, so it is something with authorization. But the repository is marked as “public”. I’m not sure what I’m doing wrong.
For me one of the main reasons was the e.V. from Germany (eingetragener Verein aka registered association) behind. It’s much more trustworthy than Microsoft or even some smaller companies.
Another reason is the accessibility. Purism makes it not easy to create and activate an account and after I tried it, it got activated while I was not at home and 2 days later it was already deactivated, while the “send me a code to reactivate” never sent a code. I was tired by this and stopped trying. I understand that they want to protect their services, but I also don’t want to feel like begging for access.
And last but not least, user0 who didn’t accept any of the other git repositories accept this one. That can be interpreted as plus.
Thanks. All good to know. I already didn’t have a good feeling about what pain might be involved in opening a Purism source/issue reporting account. Now I’m even more aprehensive.
I have been researching the pros/cons of opening a Codeberg account and the information is readily available. What I was really asking above was the nature of the missing page problem, but it looks like FranklyFlawless has answered with what seems most likely.
