matf-kabouik

I am sorry for being the annoying guy with my strong feelings here, but in my opinion any layout (1) without a right Ctrl key, (2) without a bottom left Ctrl, or (3) with the arrows block splitting the usual punctuation symbols are absolute no-go. (1) No one answered my question about how are supposed to be used the Ctrl+Alpha combinations without a right Ctrl when most those combinations imply the whole left-hand alpha block (QWERTASDFGZXCVB), but I believe it is a huge thing to consider. Those keys serve in text editing, file management, tab management, window management, terminal work,

I think one of the reasons for going ANSI is also because while ISO is the norm in more countries, it comes in a huge variety of different flavors. There's no easy way to make something that works internationally with ISO without going into too many custom adjustments that may create new problems (like those we're trying to fix). @EskeRahn I understand the goal of this layout but to me the cost of moving arrows is high and the sorting of the left modifiers comes with significant drawbacks while drifting away from something more standard we know can be achieved. It is just my opinion, noth

Changing the shape of the Return key implies hardware changes. @Craig suggested we shouldn't go that far if we want F(x)tec to consider our suggestions. He's probably right. In addition, a tall Return would mimic an ISO keyboard, whereas the rest of the layout is closer to ANSI.

I find it awkward to have /? out of the way, separated by keys that are supposed to be in a different block on regular keyboards. The reordered modifiers on the left does not really work for me, we lose many of the easier combinations we were talking about in previous posts. However I find it interesting that the new layouts we now come up with imply huge losses; that was not the case a few days ago and it might show that we finally reached a good level of optimization.

I'm convinced those are big regressions @Craig. No Ctrl on the right is a shock. How can you guys not need the right Ctrl key? I use Ctrl+C Ctrl+A Ctrl+V Ctrl+X Ctrl+D Ctrl+F Ctrl+S Ctrl+W Ctrl+Q Ctrl+Z Ctrl+R (Ctrl+Shift+R conveniently replaces Ctrl+F5 in browsers @EskeRahn) every single day on my Pro¹. Those are among the most frequently used combinations in daily use (not just nerd use) and all corresponding alpha keys are on the left so we need the right Ctrl key. Easy Shift+AltGr, however, is not a argument strong enough to justify the trade-offs that it implies. I am an us-intl use

Damn you're right about Ctrl, thanks! I didn't forget it was wired but just reused the wrong base layout! It's fixed in my previous post. We have been thinking about the position of Fn, but actually what is common on laptops (and not necessarily always done) doesn't make much sense on the Pro1 with touch typing and other keybindings. Fn here would be used for F1-12, Del, and Home/PgUp/etc. Those are rarely combined with the adjacent keys in the placement you suggest, i.e., Ctrl and Super. Ctrl+F1-12 and Super+F1-12 exist, but are infrequently used, and mostly user-configured. By cont

I agree with EskeRahn and discussed that on Discord too. Del key is used not only for text, but also software keybindings, which won't be rare in Mobian/Arm/Manjaro/LXC containers. I took the example of Gimp but file managers is a much better example. thanks. If Fn+Backspace can work in all OSes, then it should be acceptable. Ctrl + Alt + Del is not so commonly used, it's more something you use when there's an issue so maybe it's acceptable even if hard to type with Ctrl + Alt + Fn + Backspace? Actually on my proposal where Alt and Fn are next to each other, it's not much harder than with

We're getting close. Merged the one you posted earlier and the one I submitted a few days ago: - Fn next to the right of all modifers because Fn almost never combines with other modifiers on full keyboards - On Pro1, however, Fn could allow F1-12, and therefore would actually combine with Alt for Alt+F4 for instance. Alt and Fn are next to each other, so that works with one thumb. Ctrl+Alt+Del even doable with some acrobatics (Ctrl+Alt+Fn+Backspace) maybe? Fn+Space also doable with one thumb to bring up the language popup on Android. - Sym next to left Ctrl because I paired Sym a

I believe the Pro1x would justify a special edition keyboard with blue instead of yellow, even for the logo since this is a limited edition. Your super is centered too (but will be replaced by the logo anyway).

As said on Discord, I'm having a hard time trying to figure out what I think about it. Moving Del is a bold move, but the result with all alphanumeric keys located where they should (except `~ but it's close enough) is sexy. My concerns are: - What will new people think when they see the device for the first time? It's a silly thing, but we don't want people to think it's a flawed design just by looking at it when it actually isn't bad at all to move Del. - What are the risks of having Del next to modifiers, alpha keys and space bar? Discussed above, it's true that the risk is n

Pretty much what Onboard offers for virtual keyboard on Linux, but not sure if you can toggle repeat vs extra symbols on long press. This couldn't be done with base UNIX tools like xkb and therefore it is something different than us-intl, but perhaps it can be developed specifically for Android/LineageOS (or already exists?). Such solutions do not require much optimization of the keyboard relative to the conventions though, and they're not generic enough to come by default on all systems. It's also significantly slower than typing modifer+alpha to get a special alpha symbol.

Those are all taken care of with the us-intl layout, either with or without dead keys, thanks to the AltGr keys. But that's software as far as I know, the important thing is to make sure the keyboard can do it with replicated left and right AltGr. This is not useful on full keyboards, but inevitable with thumb typing. You can have a look at Craig's detailed layout to see where are all those internatinal symbols. One could argue that it is useful to print those extra characters, but in general us-intl is not printed, since it mostly takes advantage of third-level symbols on keys, which are almo

Having Backspace and Delete on the same key would work for me but, like you, I am really not sure this can be achieved for all firmwares/OSes. For instance, Delete and Backspace are not functions that we can assign in a xkb configuration file, so it's not straightforward to map it to Super + Backspace as far as I know. Perhaps a porter/developer with a good knowledge of all OSes and of the kernel like NotKit or Tdm could tell.

Could this double engraving work for everyone? Let me explain. Considering the bottom label is always the main one on keyboards, these swapped double labels make it look like default is Fn on left key, and AltGr is default on right key. But with some flexibility thanks to the top double label. Those keys can produce distinct keycodes since they are not wired, therefore it is doable. Changing this in firmware or software is possible, while keeping the same labels that work in all situations. Depending on OS or user needs, firmware or software (respectively) can be adjusted by por

Actually those third-level characters are not often upper case, and in that case they can still be typed with caps lock on Linux. Compose keys work too (here is ẞ typed with a compose key on Pro¹), and dead keys for diacritics of course. But, most of all, there is now a nordic keyboard with all those special characters mapped where they should be. Of course, a fraction of users will use qwerty us-intl instead of their native layout, just like I use it instead of azerty, but in that case there's a decision to use qwerty instead of something specifically designed for the other language, and

You're referring to ISO keyboards, but those vary greatly between countries, probably too much to be good candidates for a generic international qwerty on our device. US-intl is more or less designed for ANSI, and the rest of the layout resembles more the ANSI layout (with <> to the right for instance and on first level), except for this extra key to the left of Z. With only one key left to Z, I therefore believe it would be best to keep `~ on that side. https://upload.wikimedia.org/wikipedia/commons/thumb/5/51/KB_United_States-NoAltGr.svg/420px-KB_United_States-NoAltGr.svg.png

Okay, that's useful information, thanks. They both are associated to the same keycode (108) in xev, but that may be set at kernel level instead of hardware limitation. I would still keep all three modifiers paired (Ctrl, Shift, ???) and would prefer other keys to be placed differently as described in above posts.

Abandoning the right Ctrl is both criminal and impossible with the current hardware. It's probably the most used right modifier when thumb typing, due to A, X, C, V, R, Q, D, F, S, Z all being on the left. I also would die of brain seizure if the bottom left key was not Ctrl, which means it has to be replicated on the right instead of YA, but then we lose Right AltGr again. Also, moving '~ to the right is going to be very awkward if the goal is to make the keyboard resemble more full-size keyboards, I don't see why it should be to the right while \| is moved to the left. It's not possible

Ah, I don't disagree, I wouldn't change much on the current keyboard, especially if we take into account the electrical wiring constraint! But there are things that could be improved. On mobile OSes, there probably aren't many use cases other than text selection and arrows, but the Pro¹x aims at being a Linux phone, and Liangchen himself mentioned Mobian and pmOS as alternative OSes. Add to that desktop distributions running in chroot and LXC in SFOS, or Android (I think there are ways to run desktop distributions too, albeit with more limitations). In those, just the terminal gives pl

Please keep the bottom left key as Left Ctrl. It's standard, most users use left modifiers more often than right modifiers, and Ctrl+Shift is a pretty common key combination. Since it is electrically wired to the Right Ctrl, this also means that the key to the right of the space bar should be Ctrl too. Other than that, I would be happy with: Ctrl, ???, Fx, Alt, \|, Space, Ctrl, ???, Left, Down, Right Where `???` could be a neutral symbol to make both Fn and AltGr users happy. I would not use a distinctive color for Shift and shifted symbols (second-level chars) with the new layo

I agree with @Doktor Oswaldo, but I'm a us-intl user so I'm not 100% neutral. No one is. I don't see the point in having duplicated Fn keys, since all functions seem to be on the right of the keyboard or used only occasionally, not for typing (F1-12, provided those can be triggered with Fn on Android; not sure). Removing one AltGr would mean having two Fn keys, given that those are electrically wired, and this doesn't make more sense than two AltGr visually, but on top of that is not really fulfilling a need like duplicated AltGr do. The Fx key could be used as Fn in my opinion, sinc

I'm not 100% sure either, but I never managed to distinguish them in OSes at least. They both report keycode 108 for me in Debian using `xev`, while `Alt` is keycode 64. It might be due to those two slant arrow keys being mapped the same way in kernel, but I believe it's hardware wiring.

I don't think that's possible without hardware changes, since all duplicated modifiers (Shift, Ctrl, yellow arrow now labelled AltGr) are wired together if I understood correctly. Swapping Fx and AltGr would therefore mean that right AltGr becomes Fx too. I also edited my post to fix a similar issue: it's not possible to have AltGr immediately to the right of the space bar for the same reason, it has to be Ctrl, or else the left Ctrl would become AltGr too (meh). Could you please update your quote so that the quoted image is not the old one? I'm adding it here too so people just reading t

I believe I would be pretty happy with that. Possibly with a different color for Shift and second-layer chars (yellow, if we keep it close to the current keyboards), but keeping those white would work too since this layout is now pretty close to desktop keyboards, so there's no need for extra hints on key combinations everyone is already expecting. Depending on how Fx is mapped, perhaps there would be ways to use it as Super on OSes that have a use for it. I do not know. Ctrl is still immediately after the space bar because we know both Ctrl keys are wired, so it's not possible

This (maybe without the printed third-layer characters, because changes are sometimes useful for specific needs, but I wouldn't mind too much if they were printed anyway because they help new users with the default us-intl, even if it doesn't match my own configuration). And this. But with AltGr next to Ctrl, not Fn. I don't think combinations of other modifiers with Fn are common, while Shift/Ctrl/AltGr combinations are. I agree with Slion, it's really important to keep Shift, Ctrl and Yellow arrow clustered together on the bottom left corner. I would keep direction arrows on the