matf-kabouik
-
Content Count
211 -
Joined
-
Last visited
-
Days Won
7
Posts posted by matf-kabouik
-
-
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, nothing more.
-
1
-
-
Just now, brunoais said:
I prefer a tall Enter key than wide Enter key. Then the key between Enter and Backspace would go where Enter is shortened. However, that's not how the PRO¹ is designed but I wanted to get that out of my system.
Given the options, A is the closest to how I use the keyboard and how I need to use the keyboard.
I also like that we turn the "dedicated" symbol key into another modified (Fn is written on the keyboard but officially, it can be the Hyper key! Oh wait... There's no hyper key in android... Oh well...)
Ok so...
- Ctrl -> KEYCODE_CTRL_LEFT
- Shift -> KEYCODE_SHIFT_LEFT
- Alt -> KEYCODE_ALT_LEFT
- AltGr -> KEYCODE_META_LEFT
- FX -> KEYCODE_SEARCH
- Fn -> KEYCODE_FUNCTION ?
Can some one please confirm if these are correct for me?
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.
-
1
-
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 user and I use the extra symbols several times in each average sentence in my native language. Yet I don't miss an easy Shift+AltGr on the current layout. There's usually only one upper case symbol per sentence, and it's a basic alpha symbol in the vast majority of sentences. Plus, when upper case is needed, there is dead keys and Caps lock to type them with equal convenience. And now Scandic and Azerty layouts strongly reduce the necessity of an easy Shift+AltGr for international users. Losing Ctrl+Shift (plus making the location of those two major modifiers less conventional) is a huge loss.
For these reasons, my opinion is set that the best so far are the following (ignoring label color hues, just key locations):
A.
Please don't get fooled by the quality of the PNG: the labels are equally legible, I just used the editor's builtin PNG feature and it's not good.
B.
I am not sure yet if I prefer the layout B where you moved the left modifiers. It's not clear to me if the ability to Alt+Fn, Alt+Ctrl and Super+Fn outweighs the ability to easily Super+Alt, but it's an interesting alternative and I am still hesitating. I would see all the others layouts as regressions even compared to the vanilla Pro¹x layout.
-
1
-
-
37 minutes ago, Slion said:
@matfYou forgot Ctrls are hardwired.
Also I rather have Shift, Ctrl and Fn in the left corner as that's how it is on most keyboards these days. Except ThinkPads 🤣
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 contrast, having Alt next to Fn makes a lot of sense for Alt+F4, Alt+F2 and Alt+F3. Same for Ctrl+Alt+Del we discussed above.
Ctrl and Shift can still be chorded with Fn relatively easily because they are on both sides of the keyboard, whereas there is only one Alt_L, so it has to be next to Fn to be chorded with one thumb. Likewise, this way the only Alt is also allows located next to Super for other combinations frequently used at WM level.
On laptops, none of this has any significance since combinations can all be done easily with multiple fingers whether or not Fn is in between modifiers. In fact, the Fn sitting between Ctrl and Super on my laptop annoys me a lot because it always get caught in my Shift+Super and Ctrl+Super combinations in i3. 😮
-
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 a dedicated Del key, it is still a 3-finger combination.
A variation of the above with same label on both AltGr keys despite their independence, because not everyone agrees that independent keys could be labelled distinctively (it admittedly clutters the keyboard):
-
1
-
-
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 and AltGr. They are slant arrows right now. I know they are not wired but still I think it's best to keep them in the same relative positions. Not the same label on each because not the same keycode, except for those who need Alt_R on both sides for us-intl: they will configure it to use Sym and AltGr, I think both labels are relevant for the purpose of bringing extra intl symbols because that's basically what they mean (Fn wouldn't be relevant, however). One could argue they could be labelled identically, but I think that would be confusing. All keys labelled identically are wired together, those that can report different keycodes should be identifiable from labels.
- Fixed a few mis-aligned labels. Also I noticed on the Pro1, keys of the bottom row have centered labels except the leftmost and rightmost. I tried here but it doesn't work because of second labels. I think this is the best balance here.Also, colors: from IGG pictures, I'm getting #3c93be for the casing. I used #0173ae here, it's close but a bit paler and contrast is good, also light enough for backlight. In any case, we just need it to look close enough to the casing here, F(x)tech would use the exact color they need.
I think it is important to ping NotKit, Tdm and others before submitting a layout with Del as Fn layer, to make sure it's doable on all OSes. And that there are not other issues we would have overlooked.
-
1
-
1
-
-
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).
-
1
-
-
20 hours ago, Craig said:
re: del
Although I've stressed not needing custom layout to use any keys, not having del without a custom layout isnt such a big deal. I could much easier live without Del than slash, because can always right-arrow then backspace to accomplish the same thing. So I think it retrospect if I del were to be moved, don't print it as another fucntion on backspace key. (If people can do that themselves in custom layout. )
re:menu key
It has OS defined functions already doesn't it? In Android it brings up your menu, on my linux distro that I use it also brings up menu but I realize every distro/window manager does it themselves. And on actual microsoft windows I thought it acted like right click. But yeah I dunno if its useful. It was just a random thought for another bottom row key and perhaps useful with android and linux. But probably not worth sacrificing delete for a rarely used key, cuz people probably actually do use delete since it's available...
So how bout putting del down there instead of pipe? Thoughts on if this is better that first proposal?
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 not necessarily huge, but still needs to be considered.
- Will I get used to Del being on the left and far from Backspace and Enter? Yes, probably. More importantly, will I like to use it? Hard to predict.
- Will this be considered too exotic by Fxtec to accept the suggestion?
Benefits:
- Almost standard alphanumeric layout.
- On the one hand, easy to combine arrows under right thumb and Del under left thumb when editing. On the other hand, having Del and Backspace next to each other usually makes it easier to either delete characters to the right or to the left of the cursor when editing a paragraph and moving the cursor up and down or moving it by words (Ctrl+arrows), but really I don't think this should weigh much in the decision.
All in all, I think I like this design. Delete is never in a fixed position on full size keyboards anyway, its position varies among laptops and even USB keyboards, and sometimes it's in a separate block. I think people will get used to it, although here it's on the other side of the keyboard, which is very unusual.
Some comments:
Since you asked, I do not like the layout with Del between Super and Alt. I think it's best to keep modifiers clustered together. It's less confusing, easier to combine them, and overall I think it's tidier. My vote would be for the layout quoted in this message.
About labels, I fully understand that you said it doesn't matter at this point, you're right that F(x)tec will decide anyway. I just want to bring grist to the mill just for the discussion, and to make sure we show something to F(x)tec that would be as close as possible to a final design so that they can picture it better in their mind. I would not print the us-intl labels, there are too many people who would never use them, and us-intl can't really be the default xkb configuration when shipping the phone anyway. Those third-level characters are usually not printed anyway, users of us-intl are used to that, and deciding to print them would be an issue for those who don't use us-intl, for those who customize their xkb layout, and would raise the question as to why we didn't print the fourth-level symbols too (they're not always upper case version of the third-level ones). Therefore I would show the detailed layout to F(x)tec just to illustrate why the new placement of keys we propose is superior and a lot more flexible than the current, but not in a way that would suggest we want it printed (but that is just my opinion).
Even more minor label comments: I don't like this emoji on Alt, but I have a problem with emojis and I know it. I'd prefer plain old and nerdy or "=)". I know that's probably not an option tho. AltGr is misaligned on your layout, it should be bottom left like other keys, not center. The turquoise blue is not the same hue as the Pro1x. Of course we can still discuss whether AltGr should be AltGr, Fn, AltGr/Fn, a neutral symbol, or Fn/AltGr on one side and AltGr/Fn on the other. At this point anything would do for me, as long as we have the keys where we want them.
-
4
-
-
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.
-
1
-
-
33 minutes ago, brunoais said:
So-so.
I'd be missing áàâã,éèê,iíî,óòôõ,úù,ºª... Oh! Would that be composed with the Key next to "Shift"? Maybe just missing the "´" character, then.
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 almost never labelled. Different users speaking different languages may want to customize their us-intl too, so being too specific would ultimately mean some keys would be wrong in some cases.
I can compose ´ with us-intl-deadkeys by just pressing ' twice in a row, there should be another solution for us-intl-no-deadkeys (probably AltGr + '). I cannot comment on how well dead keys work in Android or LineageOS, though. I know support is mostly lacking in SFOS, but this isn't an issue in other Linux distributions (here's a ´ typed from Pro¹ using a Debian container).
Not sure about ª, but I assume it is doable with a compose key. I can compose ° with the key I chose as compose key for instance (in my case, Caps lock to start composing, followed by "oo"), however there is a more direct way with "Shift + Alt_R + ;" already set in the vanilla us-intl.
In worst cases, there's always unicode (Ctrl+Shift+u followed by the code of the character you want). It's not convenient for regular use and you have to know which code you need, but it can output all symbols. There are also graphic helpers to find any unicode character on Linux (here's my fork: https://git.teknik.io/matf/rofiemoji-rofiunicode). That is beyond the topic of the Pro¹ keyboard, but just wanted to show that unicode can actually be practical for corner cases where the symbol you want is not mapped.
-
1
-
-
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.
-
2
-
-
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 porters or users (respectively again) to make them be the same modifier, either Fn or AltGr depending on needs. I don't think any user would be shocked that their unconventional replicated Fn or unconventional left AltGr is written in a smaller font on the extra label.
Also, blue Super for consistency with the Pro1x casing.
[Edit] Possible ambiguity: people thinking Shift + Left Fn key = AltGr, or that Shift + right AltGr key = Fn. But would that really be a significant issue? Distinctive color for top labels of each of those two keys could sort this out, but not sure there's a need for that.
-
2
-
-
1 hour ago, EskeRahn said:
Hmm that might hold in the US, but hardly in the rest of the world in need of national characters.
Here in Denmark we don't need it (dead key accenting works just fine for rare accents), but all those with languages with frequent accented letters might feel differently.
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 probably motivations other than just the special characters. Could be for coding or other techie reasons, using multiple languages and all, but again upper case special characters are rare, caps-lockable, and compose-key-able. Dropping Ctrl+Shift causes important issues for terminal use and tiling WMs, but also any software with keybinds, which would be a huge trade-off for a phone now clearly aiming at being a Linux phone. Moving left Ctrl would make it unconventional and I see more drawbacks than benefits for Linux use and international users.
The latest suggestion by Craig is the same I proposed, with same key positioning, just some variation in double labels. In my opinion this is the best balance, close to standard yet usable with thumbs in all languages, with common Linux key combinaitons, and Android. Also, Alt on full keyboards is between Super and Space. We have two keys between Super and Space here, so we have to choose where to put Alt and \|. I think it makes sense to keep modifiers clustered together to the left (easier fat thumb combination and more feng-shui visually), therefore Alt right to Super, and \| left to space bar.
Craig played with double engraving on Discord, and posted this here. I believe it's a good solution to make all users happy, perhaps even more than a neutral symbol. This way, users who need duplicated Alt_R have AltGr on both sides, users who don't care about it have Fn on both sides, and use who want both can see the label they want on each side. Since both keys are independent, they can be made different in firmware by default, and then kept different or given the same function in software if need be.
-
2
-
-
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.
-
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.
-
2
-
-
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 anyway because this 8th key on the bottom row is wired to the 2nd, so we would have `~ twice. That is why others before have suggested moving \| to the current Sym key, it's the best non-paired key available at the bottom (there's Fx and Alt too, but putting characters in the middle of modifiers would be weird).
-
1
-
-
48 minutes ago, EskeRahn said:
But that is exactly what we already got (except the Sym), so maybe it isn't that bad after all.... 😉
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.
40 minutes ago, EskeRahn said:Just out of curiosity, except with the arrows for marking (and Visual Studio short-cuts), where do you encounter this combination? I don't think that I ever used it for other than marking on a phone, And I bet some trickery could be done having ⬈+Shift+Arrows act as Ctrl+Shift+Arrows.
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 plenty of reasons to combine Ctrl and Shift (copy/paste for instance). Tiling WMs too. And basically any desktop application with support for keyboard shortcuts is likely to have some Ctrl+Shift somewhere.
-
1
-
-
27 minutes ago, EskeRahn said:
I would suggest the bottom row as something like this:
- YellowArrow , Ctrl, Fx, Alt, ??? , Space, YellowArrow, ???, Left, Down, Right
not quite sure what to put on the ??? keys
...Actually this would be quite close the Lenovo laptops keyboard: Fn, Ctrl, Win, Alt, Spaaaaace, AltGr, PrtSc, Ctrl
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 layout, because it is now much closer to a standard keyboard, no need for extra hints.
-
1
-
7 minutes ago, Doktor Oswaldo said:
In my case definitely two Alt Gr. Because it is in the end an Alt Gr key. Yeah it looks strange because we are not used to it. But that is only a matter of time. And labelling a key FN that you use as Alt Gr makes no sense to me.
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, since it has close to no use otherwise. Or, if it can be mapped to Super and therefore get more uses, then maybe functions should be moved to Alt indeed, or just binded to Super+arrows for PgUp/PgDn/Home/End.
Using a neutral symbol instead of AltGr or Fn as suggested by @EskeRahn would totally work for me too.
-
2
-
-
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.
-
23 minutes ago, Slion said:
Would just swap left AltGr with Fn 😁
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 this page don't get confused with a layout that cannot be made.
-
1
-
-
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 to move one without significant hardware changes. Yellow arrows (AltGr) are probably wired too, hence duplicated AltGr (which is best for us-intl users anyway).
-
1
-
-
2 hours ago, Craig said:
That keyboard editor you linked is pretty cool... for fun I put US Intl (without shift) on so people would know what AltGr is for with that layout. But of course different layouts will result in different things so I dunno if it would be a good idea or bad idea to print us international, but I wouldn't be opposed.
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).
2 hours ago, Slion said:I would leave pipe next to the space bar so as to enable two double modifier shortcuts using you left thumb, Ctrl+Shift and Ctrl+Fn and maybe even Shift+Ctrl+Fn for the most skilled users 😁
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 bottom right so I didn't quote your latest layout, even though this limits the ability to combine modifiers with the right thumb, because it would be more standard and the combinations can already be done with the left thumb. Having modifiers at the right of arrows would be very confusing in my opinion. Other than that, the layout you proposed seems pretty good to me, as an us-intl user.
About duplicated third-layer modifier, as you pointed out, the constraints are really different when we're talking about a keyboard designed for touch typing. Having only one on my Linux laptop is no issue, but on a touch keyboard it makes half of the third-layer characters hard and inconvenient to compose. Since those third-layer characters are very common in other languages, two thumbs on the same side of the keyboard is not convenient enough for actual productivity. In Debian (LXC), I also use the yellow arrow (mapped as Alt) as my i3 modifier exactly because it is duplicated, this way I can use many WM keybinds easily without weird hand gestures.
But then, I don't know what are our possibilities for rebinding those at the kernel level. I know TheKit did change some things in the kernel when porting SailfishOS so that we could use Sym as /? for instance. I also was able to remap Fx as Super in xephyr (LXC) using simple xmodmap commands (but not in Sailfish nor in xwayland LXC, which has significant benefits over xephyr), but I'm not sure I could distinguish left and right yellow arrows. Are they not identical on the hardware side, like left and right Shift and Ctrl? Not sure it is actually feasible to distinguish them without hardware changes, which would close the debate.
-
1
-
tec-prox-qwerty-us-e.png.4657b52b2832d71e361b5293eaa78527.png.cc5bdd7bcdc15c5426517ca73b0b1db5.png)
tec-prox-qwerty-us-e.png.4657b52b2832d71e361b5293eaa78527.png)
tec-prox-qwerty-us-d.png.b41a9fc948d7b527cf7aa485366c288a.png)
tec-prox-qwerty-us-c.png.b221450eb300c299e47772a84c96c66d.png)
Pro1 X Qwerty Layout (Not Shifted)
in Pro1 - Thoughts & questions
Posted · Edited by matf
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, and probably other areas. I mean, they are probably the most common and widespread commands across all softwares and OSes, and we can't do them without right Ctrl.
(2) and (3) We have put sweat into getting closer to real keyboard standards, even sacrificing Del to put \| where it belongs and, together, we managed to reach a fully normal alphanumeric and punctuation block (except for right Shift but that's an okay trade-off), which was quite an achievement on a 64-key keyboard. I cannot understand how moving arrows inside this block, hence splitting it and moving Ctrl and ?/ to an isolated block with Shift, or moving the bottom left Ctrl, could even be remotely acceptable. I think those changes are worse than having \| in an exotic location, and we would do exactly what we were trying to fix: custom changes that F(x)tec did in the past or that laptop manufacturers do despite all the hate and functionality issues they create. Clearly, if Liangchen did accept any of the layouts moving left Ctrl, the arrow block, or removing right Ctrl, I would be disappointed enough to consider cancelling my pledge for the Pro1x because I would consider it a significant regression compared to the already suboptimal layout they are offering in the campaign. Now this is just my opinion and it may or may not be deemed relevant by the majority, I'm just taking part in the discussion and I fully understand that having strong feelings doesn't mean my view weighs more. However I've seen other reactions on Discord about the lack of right Ctrl or the moving of the bottom left Ctrl, so I probably am not alone.
I think any layout doing those trade-offs on Ctrl and arrows lose a lot of functionality just to maximize technicality for more modifiers. I believe functionality and genericity are far more important.
The only viable candidates (for me, again) with all OSes, use cases and languages in mind are the A and B posted above. This of course looks like I just push the ones I already posted, but B actually comes from Craig and is the same as his "3. Pretty", just with different labels. I don't think Pretty does it justice though, and it won't sell it well to F(x)tec who values functionality. I think it's the best allrounder with a good balance between keyboard standards and thumb-typing functionality across different OSes. I am not sure between that one (A or "Pretty": Ctrl, AltGr, Fx, Alt, Fn) and its variation (B: Ctrl, Alt, Fn, Fx, AltGr) later suggested by Craig. My use case with tiling window managers makes Super+Alt more important than Fn+Alt, so I tend to prefer A/Pretty, but it's hard to tell if it's objective or just biased by my use case (which wouldn't be a good argument). Another thing to consider is consistency: it is a good idea to have the same easy key combinations on both sides of the keyboard. A can do Ctrl+AltGr both on left and right, which means keybindings using this combination can be used with all alpha keys. For non-us-intl users who won't have anything on third level of their keys, this could be an important improvement (AltGr can be interpreted as normal Alt while Alt can be interpreted as a different modifier). Only the A keyboard allows that. With a tiling WM for instance where many keybindings are configured, it's important that the same patterns can be used with both hands to maximize the number of shortcuts while keeping them logical. Tiling WMs on the Pro¹ could soon be more than just the nerdy thing they currently are with just SFOS+LXC, because Mobian/Arch/pmOS are progressing and attracting more users, and even Phosh can make use of more consistent keybindings with both thumbs.
Regarding labels:
- I suggest using the same blue as the one used on your space bar: #3B76A4. It would look more consistent and also is closer to the Pro1x casing, it may maximize the chances that F(x)tec picks up the idea.
- Wasn't there a consensus that Sym is relevant only for Android and that AltGr is more conventional and OS-agnostic?
- Same with blue slant arrow. It's fine by me and it may please F(x)tec since they used slant arrows before, but isn't Fn just more logical and straightforward? I had tried ◯ ⛶ ◌ ⬚ on the A and B layouts I posted above, but didn't see any significant improvement compared to ↗, while Fn looked just like what it does: function keys. On the original F(x)tec layout, I guess ↗ makes sense because it's an alternate shift that can produce symbols; not on our proposal here, only functions.
Finally, a couple final words on Del: I'm sold to it because it allows achieving superior layouts in all regards. However, this will be a very significant change compared to Scandic, Azerty and Qwertz layouts and it is hard to tell if F(x)tec will be prepared to sell layouts that have not the same basic principles. We should both come up with an alternate idea without sacrificing Del (putting back \| to the bottom I guess), and propose equivalents for the other layouts offered by F(x)tec. I'm sure they will want consistency across all layouts they ship, not just a superior yet weird Qwerty that doesn't fit in the rest of their offering.