As for multiple keyboard Shifts, I'm guessing I'm one of the few who looks at the right keyboard Shift key as user remappable, if so wished. SysRq, Print Screen, Scroll Lock, Pause/Break, Escape, Compose, Degree, Yen, and any number of others could usurp it, if the user likes.
Here's your opportunity to test the truth of this(and putting an end to this crying wolf game). Remap one of your right side Pandora keyboard keys to another Right Shift. Then press both Right Shift keys together. What happens? Reassign keyboard Right Shift with the Yen. What happens now?
Its suddenly different because french uses too many letters to make that happen in the ordinary way. Italian has sort of the same issue,
because they have two diactriced letters on the same key.
Not that they shouldnt be able to do that, but for interlingual purposes, ive tried to do away with any such hacks. One modifier to do special language,
+1 modifier to do big letters special language.
Unfortunately we have not that many keys, so the least hacky way i found to do it was to use start and start+select. Its not ideal, but it has way less
caveats than putting ctrl on select and alt on start.
I still don't see why pressing Shift (or Caps-Lock) to get upper case French letters is a problem. Like I said when I was staying in France I recall having no issue with that.
But you werent using the affected keys, were you ? On a regular french keyboard pressing "É", "È" or "À" is not possible. Yet it's doable on a french-canadian keyboard (like the one I'm using here)
Its suddenly different because french uses too many letters to make that happen in the ordinary way. Italian has sort of the same issue,
because they have two diactriced letters on the same key.
Not that they shouldnt be able to do that, but for interlingual purposes, ive tried to do away with any such hacks. One modifier to do special language,
+1 modifier to do big letters special language.
Unfortunately we have not that many keys, so the least hacky way i found to do it was to use start and start+select. Its not ideal, but it has way less
caveats than putting ctrl on select and alt on start.
I still don't see why pressing Shift (or Caps-Lock) to get upper case French letters is a problem. Like I said when I was staying in France I recall having no issue with that.
A standard French keyboard in France looks like this:
Shift+ éèçàù produces not ÉÈÇÀÙ but 2790% on an AZERTY keyboard. Also note that all the shift symbol pairs are different than US-QWERTY (except =+), Keyboards layouts can be weird. For example, the French keyboard has dollar sign ($) as a primary (unshifted) key -- why?
Also it has period (.) only as a shift symbol, while semicolon ( and exclamation mark (!) are primary keys. I wonder if French people think it is more important to build long sentences and to shout than to end sentences with normal period.
Many standard keyboards are a bit weird in terms of shifted letters with diacritics. The Italian and the Swiss keyboards are even worse than the French one in that respect.
It is the country that made SECAM and ISDN. Trust the french to do something special. And yes, the country-denominator is warranted in this regard.
Importantly the lower case variants of those keys are on 2790 on a french keyboard, so they should be on the pyra aswell. It will unfortunately be one modifier away, since laziness cant be afforded with less keys. They are only that important to the french, and to the whole community, there are more important things to have in standard ways.
With that same modifier, which i propose on a dedicated select, since that is uncumbered it is possible to also do the higher-case variants. With all major western europa covered. (where the pandora sold any units, and where the pyra can hope to sell any, which is a bit more)
Albeit you will have to learn where the extra letters for your langauge are, since its a semi-new thing, and they are obviously hidden. For interlingual use, its very nice, because its always available.
AltGr has this functionality by default in a lot of places, but doing an overall with that by default is problematic since many people have different expextations about what it does by default
for them. I for example, as a Norseman, expect to be able to type ð to write old-norse/icelandic
I think that is a good compromise, and it does away with the need for caps-lock. I think ctrl+shift, like on NeXt computers, is good if you insist on doing it the standard way. The reason is because we cant waste a key on a way to type that is marginal (french, italian) as opposed to English, german, and at the same time is inefficient.
--- sounds like a very silly idea. Even full-size keyboards don't do that, e.g. the number row contains both numbers and symbols, each of those keys do at least two things.
My latest proposal does get meaningful efficiency gains in a lot of languages. German obviously. But also French, Spanish, Portuguese, Dutch, Italian, Finnish.
Many people expect to have to use dead diacritics for many of their letters. There simply does not exist a keyboard that has all the letters used in French (àâçéèêëîïôœù) as dedicated keys. Same with Spanish (áéíóúüñ), Portuguese (ãâáàçêéíóõúü) and Dutch (áàäéèêëíïóöúü). Italian keyboards have lowercase-only àèéìòù, but I'm pretty sure that they would be fine with dedicated àèé (which can be used in upper case too!) and dead grave.
I am sorry about not including Å Æ Ø while still including a "dead greek" key, but keep in mind that the Greek letters are not only used by Greek people (even though Greece has a larger population than any Scandinavian country, so don't dismiss them too quickly!), and that it only takes up 1 key, while Å Æ Ø take 3 keys. Also I think that having an ÜÖÄ cluster to remap things to is "good enough" for most Scandinavians (especially the Finnish, who only really need ÖÄ). I don't think separately labeled Å Æ Ø keys would be a huge improvement for Scandinavians, especially since there is no way to arrange their relative positions in a way that makes the Norwegians, the Danish and the Swedish all happy at the same time.
The only way around doing shift layers, is having a keyboard that is 3 times as big, which is again inefficient as a keyboard, because you will have to learn positions on a bigger keyboard, and move your hands more.
Mixing modifiers with letters, is ugly, and it breaks with convention and expectancy. Yes putting [ ] on letters that are close to the [ ] key is in many ways good, but its far from equivalent.
The greeks dont have money to buy 500€ handhelds. That is the reality. They didnt with the pandora, they wont now. And their alphabet/keyboard convention doesnt fit. So even if they did, it would be a sub-optimal sale for what is mostly a burden on everyone.
Italian, Spanish, and French have both dedicated keys for letters, and diactrics, the latter with dedicated keys too. Doing compose, which is second rate to begin with, in a non-dedicated way, with non-conventional symbols, is just not answering the question for any of them. Its at best ok for interlingual use.
Dedicated keys, for dedicated letters, and language-modifiers, as per standard keyboard layout, is a goal. Yes having these keys in some other way, somewhere else, is a benefit over not having them at all, but its a joke compared to a real keyboard/typewriter.
Position is typing, thats how you know how to type. Yes there is a use in having labels, for making the treshold of entry lower, and accept a more wide userbase, but changing position and concepts has proven to be extremely prone to mass market failure in terms of keyboards.
Any number of ways are better than using limited keyboard real-estate resources on hacking in greek letters. No way is better than doing it that way. And yes, its used in electronics too, so i have "a use" for it, but i just dont see the point in having it. I assume this is a shared sentiment among the people who are exposed to it somehow.
Its suddenly different because french uses too many letters to make that happen in the ordinary way. Italian has sort of the same issue,
because they have two diactriced letters on the same key.
Not that they shouldnt be able to do that, but for interlingual purposes, ive tried to do away with any such hacks. One modifier to do special language,
+1 modifier to do big letters special language.
Unfortunately we have not that many keys, so the least hacky way i found to do it was to use start and start+select. Its not ideal, but it has way less
caveats than putting ctrl on select and alt on start.
I still don't see why pressing Shift (or Caps-Lock) to get upper case French letters is a problem. Like I said when I was staying in France I recall having no issue with that.
A standard French keyboard in France looks like this:
Shift+ éèçàù produces not ÉÈÇÀÙ but 2790% on an AZERTY keyboard. Also note that all the shift symbol pairs are different than US-QWERTY (except =+), Keyboards layouts can be weird. For example, the French keyboard has dollar sign ($) as a primary (unshifted) key -- why?
Also it has period (.) only as a shift symbol, while semicolon ( and exclamation mark (!) are primary keys. I wonder if French people think it is more important to build long sentences and to shout than to end sentences with normal period.
Many standard keyboards are a bit weird in terms of shifted letters with diacritics. The Italian and the Swiss keyboards are even worse than the French one in that respect.
Was there a reason why French keyboards weren't designed so that éèçàù were accessed with AltGr, like many others languages do? That would have allowed Shift to do a proper case change.
The greeks dont have money to buy 500€ handhelds. That is the reality. They didnt with the pandora, they wont now. And their alphabet/keyboard convention doesnt fit. So even if they did, it would be a sub-optimal sale for what is mostly a burden on everyone.
Including Greek letters on the layout would be a fool's errand due to the sheer quantity of distinct letters, but to say Greeks, all of them, do not have money to buy a Pyra is a presumptive generalization en masse. Consider the plastic case for the Pyra is made by Form Action.
Was there a reason why French keyboards weren't designed so that éèçàù were accessed with AltGr, like many others languages do? That would have allowed Shift to do a proper case change.
Yes. They wanted their letters available without having to use modifiers. Just like the Germans, the Scandinavians, the Italians, the Czech, the Hungarians, etc.
As promised earlier in my news post, here is the thread about the keyboard layout.
First of all, thanks for all the discussions and threads you already had here at the boards - a few interesting ideas arose, and one came very close to what I had in mind.
Let's start with some facts first:
The keyboard should be standard enough to be used by every normal user
It should be balanced between text typing and coding
It should have most of the keys a normal keyboard has (i.e. Pandora keyboard has issues with DosBox).
The main languages used where the Pandora sold are English, French and German. It should support these languages as good as possible (with English being the main one)
We should have a maximum of three characters per key: One with a single keypress, one with Shift and one with AltGr (which replaces the old Fn-Key)
"standard enough" is a bit vague, but I guess being US-QWERTY based (not DVORAK or something like that) is the most important thing here
I think my proposal works well for both text and coding
It has all US-QWERTY (i.e. ASCII) symbols and the important extra letters for German and French. The DOSBox thing has been discussed a lot -- let's just say that my proposal is as good as Saber's in that respect
My proposal supports English, French and German. In particular for French it is a big improvement compared to Saber's original proposal.
There only two labels per key in my proposal, but in some cases up to four actions per key. This is the same as in Saber's proposal (e.g. kKäÄ)
Putting the most-used keys in the best positions is what I tried to do (mostly based on this: http://mdickens.me/typing/theory-of-letter-frequency.html).However, of course this requirement obviously conflicts with being "standard enough" (i.e. respect US-QWERTY layout), because we all know that QWERTY does not put the most-used keys in the best positions (not for finger typing and also not for thumb typing).
The keyboard will have two different colored labels (so basically the same as the Pandora had).
Adding more colors will make things more expensive, and the keymat IS already more expensive because of the backlight.
Okay, of all the keyboard layouts I've seen at the threads you created, this seems to be nigh perfect in my opinion:
My proposal is also mostly a standard US-QWERTY keyboard. I claim it is even closer to US-QWERTY than Saber's, because: 1) it has `~ in the expected position (top left) and as a pair on one key, 2) \| are on the correct row and next to one another, 3) { } are next to eachother, like it should be in US-QWERTY, 4) _-+= are much closer to their expected positions, 5) ; : ' " are much closer to their expected positions, 6) ,< and .> are at their expected positions (right hand side, close to space), 7) Esc is closer to its expected position (very top left, above the number row instead of below), 8) PrintScreen and Pause are available
same
same, plus much better support for French: àèé directly available, cedilla (¸) available to make ç, circumflex (^) available to make âêîôû, diaeresis (¨) available for ëï
I'm not sure what exactly "normal characters" means. I don't have µ § € labeled as such, but I have included a better / more general mechanism: GREEK so you can easily type all Greek letters (not just mu), Compose so you can easily type all sorts of special symbols like § ¶ ‽ ¿ ¡ or whatever you want, and a general currency symbol ¤ which could just produce € if you want, or £, or ¥, or all of the currency symbols in the world using the "dead currency" mechanism
I don't have two shift keys, because I do not think it is useful. Firstly, you should use the shoulder buttons, it is a great mechanism to do modifier keys (not just Shift). Secondly, just like Fn is a sticky key by default on the Pandora, Shift could also be made sticky. This is a simple matter of configuration. If you really don't want to use shoulder buttons, you can make the keyboard Shift key sticky and the problem is solved too. Thirdly, having three Shift keys (two on the keyboard and one shoulder button) can cause confusion in both software and users, because standard keyboards have only two Shift keys. Finally, an extra Shift key means one key is effectively wasted (of course users can remap it, but in terms of the default mapping and the labeling, it's a wasted key)
no difference for Alt-F4. Thanks to the shoulder buttons, you can do L1+R1+4 which should be much easier than the keyboard-only approach.
ESC is a single key in my proposal.
Acute (´) and circumflex (^) are not missing in my proposal. ° is not explicitly labeled, but a much better and more general mechanism is available via the MATH key.
+, -, = are easy to reach. In general, the hard-to-reach middle section (TYFGHVB, roughly) only has infrequently used symbols in my proposal.
What I cannot tell is:
How is the layout for devving (vim, scripts, code, etc.)?
All needed characters there?
Can most used characters be easily reached or do we need to move around a bit?
What do you think?
Please post any issues and suggestions you have here - so we can rearrange everything a bit so it's useful for everyone.
But please do NOT post completely different keyboard layouts... we had a lot of those already.
Instead, post why you like a different one better and link to it on the existing threads.
And be rational - there is NO layout everyone loves. What we need to find is the best compromise for all users and usecases.
_ ; = " - / { }
_ is in a slightly better spot in my proposal (Meta+U vs Meta+V)
; is in a good spot in both proposals, but closer to the expected location in my proposal so a bit easier to find
= is in a better spot in my proposal (Meta+P vs Meta+G), and also closer to the expected location
- is in a good spot in both proposals, but closer to the expected location in my proposal
/ is in a good spot in Saber's proposal, and in a perfect spot in my proposal (it is a Meta-mash combo, like Tab on the Pandora)
{ and } are in a better spot in Saber's proposal than in my proposal if you consider keyboard-only typing; if you use the shoulder buttons they are in a similar spot except that it's easier to type a pair { } in my proposal.
So overall, I think for coding, my proposal is better than Saber's.
For command line use and shell scripting, my proposal is slightly better, e.g. because ~ (home dir) is available in its normal spot as a regular key.
I am quite confident that my proposal covers all use cases and improves upon Saber's original proposal for some of them:
natural language: English, German and French are very well covered, as well as a lot of other European languages (cf. MES-1 / WGS coverage chart)
desktop applications: thanks to the four shoulder buttons, all shortcuts should be easy to chord (including F-key combos). Also the dedicated Esc, Tab, Ins and Del keys should give a nice improvement compared to the Pandora. I didn't label an explicit Context Menu key because usually Shift-F10 does the same thing, and that should be an easy combo to press in my layout, even without using shoulder buttons. Most laptops don't have a context menu key either.
window managers: Alt-Tab (and Shift-Alt-Tab) should be much easier than on the Pandora, especially if you use shoulder buttons. Also some window managers like Ubuntu's Unity use Alt-` (and Shift-Alt-`) to switch between different windows of the same program: in my proposal ` is above Tab, just like on a normal keyboard.
command-line: dedicated Tab for tab completion, easy-mashable slash (/) and tilde (~) in the expected position
coding: close to US-QWERTY, much better than the Pandora
science & math: MATH and GREEK make it easy to input all the scientific symbols you want, anywhere (e.g. irc, e-mail, LibreOffice, Firefox, etc)
gaming: since the game buttons are mapped the same way as on the Pandora (just two extra shoulders and two extra action buttons), we know it will work and it will be backwards compatible. Dedicated keys for ` (console in fps games) and Esc should be an improvement too, as well as the Pause key which is actually used to pause some games and emulators.
After 71 Pages I come to the personal conclusion that one single layout does just not satify everyone. So the logic suggests to make various layouts to cover the different regions, at least the major ones.
After 71 Pages I come to the personal conclusion that one single layout does just not satify everyone. So the logic suggests to make various layouts to cover the different regions, at least the major ones.
It really took you 71 pages? For the latter part of your statement, I don't believe making different keymats for other regions is feasible due to cost.
After 71 Pages I come to the personal conclusion that one single layout does just not satify everyone. So the logic suggests to make various layouts to cover the different regions, at least the major ones.
It really took you 71 pages? For the latter part of your statement, I don't believe making different keymats for other regions is feasible due to cost.
I don't think region-specific keymats would be a good idea, because:
Other than shuffling the letters and number row symbols around to the QWERTZ and AZERTY positions so people feel more "at home", there are not enough keys to really make it significantly more efficient than one universal layout, e.g. a German keymat cannot look like a real German keyboard with dedicated keys for ÜÄÖß, because we simply do not have room for them.
It would add cost.
It would make ordering and shipping more complicated.
It would make the logistics harder (how to estimate how many of each regional keymat to order? there will be more "wasted" / unsold keymats)
It would make software support harder, because Pyra devs cannot count on one single default layout
In other words, relatively little gain, big loss.
I do think that it is possible to make one single layout that satisfies everyone. Not everyone will love it, obviously, and there are lots of things that are mostly a matter of taste, even stupid things like the color for the auxiliary labels. But I do think that it's possible to have one single layout that works 'well enough' for everyone*.
* where "everyone" is defined as Europeans, Americans (North/Center/South), and Australians, to the extent that they use Latin-script based languages, and they are not comradekingu.
I do think that it is possible to make one single layout that satisfies everyone. Not everyone will love it, obviously, and there are lots of things that are mostly a matter of taste, even stupid things like the color for the auxiliary labels. But I do think that it's possible to have one single layout that works 'well enough' for everyone*.
That may be true, but a layout where the same dead key will create umlaut or double acute depending on the combination, is a cute experiment but most probably not that layout. Just having a US-QWERTY layout making adequate use of the Pyra's additional keys (e.g. B-Zar's layout) would be much preferable compared to the Pandora as well as your so called "multilingual" layouts.
Has this been mentioned elsewhere in the previous 71 pages: once a layout has been agreed, is there any potential for this layout to become a standard? Could be pretty neat..
I do think that it is possible to make one single layout that satisfies everyone. Not everyone will love it, obviously, and there are lots of things that are mostly a matter of taste, even stupid things like the color for the auxiliary labels. But I do think that it's possible to have one single layout that works 'well enough' for everyone*.
That may be true, but a layout where the same dead key will create umlaut or double acute depending on the combination, is a cute experiment but most probably not that layout. Just having a US-QWERTY layout making adequate use of the Pyra's additional keys (e.g. B-Zar's layout) would be much preferable compared to the Pandora as well as your so called "multilingual" layouts.
I would propose that my dead key on " always creates umlauts, except when you use it on already umlauted letters. So ¨+U produces ü, but ¨+Ü produces ű. Or we could just use the Compose sequence convention and use = for the double acutes. The point is: double acutes are only used in Hungarian so I don't want to have them explicitly labeled, and there are plenty of ways to make sure that they're still available in case anyone needs them. I'm not trying to optimize for Hungarian.
A layout without labels for üöäß etc is fine for me, but it does not seem to be what ED wants. And I think that most Germans would prefer a layout that has üöäß over one that forces them to map those keys themselves (and remember where they put them) or to use some kind of less efficient method like Compose sequences. Just like writing French is more efficient if éèà are available in one thumb press. I think it makes sense to minimize the number of people that are forced to manually configure/remap/remember things, and to maximize the number of people that can simply use the default layout, out of the box.
I mean, what is the point of a backlit keyboard if looking at the labels is pointless?
After 71 Pages I come to the personal conclusion that one single layout does just not satify everyone. So the logic suggests to make various layouts to cover the different regions, at least the major ones.
It really took you 71 pages? For the latter part of your statement, I don't believe making different keymats for other regions is feasible due to cost.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
