- Joined
- Jan 18, 2010
- Messages
- 11,418
I personally like it, but I suppose as an English only speaker my opinion is weighed less.Is this really too much clutter?
I personally like it, but I suppose as an English only speaker my opinion is weighed less.Is this really too much clutter?
I say no, but I'm in favour of three characters per key across the board.Is this really too much clutter?
Au contraire, mon frère! English-only speakers are an important minority in this community, according to the language poll!I personally like it, but I suppose as an English only speaker my opinion is weighed less.Is this really too much clutter?
Dont get me wrong, I think it is way cleaner than some that has been proposed and I have loads of respect for the work many here has put into the layout and keymat. but I count 7 red prints that i with 100% certainty will never use (german and french?)- I will still have to Spend time on them every time i try to find a symbol my fingers dont know. When i look at it, i clearly see it is not really inteded for norwegians. Compose key for for æ and å, and a presumably dead strike key for ø will take a long time getting into my fingers, these are dedicated on all norwegian keyboards and I will need to remap these.Is this really too much clutter?
_wb_, ghostpatch, Sepulep, comradekingu, Ziz, EvilDragon, FIQ, Lykurgos, LEOXD, hns, Mute, WizardStan, rygD, Pritchy, Kiga, Ryo Hazuki, _jr_, Levi, Burb, N3Cr0, khalismur, nobgu, 3xcl4m4t10n, xiongxioi, Fahrstuhl, pndrsky, Djhg2000, Ligachamp, F_Slim, Lafazar, gardrek, Majin Wamu, laserbeams, mzw, ible, Lennaick, Løra (Lolla)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.
I don't think region-specific keymats would be a good idea, because:
In other words, relatively little gain, big loss.
- 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
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.
Yes, Norwegians will have to remap, or use something like US-International with Æ Å Ø on the AltGr layer (where AltGr would be a shoulder button). They are in my opinion too small a language (even if you add Danish too) to "deserve" three extra labels. If more labels are added, ç and ñ would get higher priority than å æ ø.Dont get me wrong, I think it is way cleaner than some that has been proposed and I have loads of respect for the work many here has put into the layout and keymat. but I count 7 red prints that i with 100% certainty will never use (german and french?)- I will still have to Spend time on them every time i try to find a symbol my fingers dont know. When i look at it, i clearly see it is not really inteded for norwegians. Compose key for for æ and å, and a presumably dead strike key for ø will take a long time getting into my fingers, these are dedicated on all norwegian keyboards and I will need to remap these.Is this really too much clutter?
Trying to keep track of _wb_'s layouts is like herding cats.Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)
By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.
One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.
- Neelix
That makes sense, too. But why not provide a default that works well for English, French and German (the three languages specifically mentioned by ED), and do the rest with software as you describe?Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)
By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.
One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.
- Neelix
We don't need a third color for that: just big and bold for the ASCII symbols, and small and thin for the (default) foreign letters.Another option would be to do something like this with the English standard Fn layer characters in bold and the rest 'standard'. I wish we could sneak in a 3rd color - actually just a darker shade of the 2nd color - but that would be a 3 color print job and more expensive. I'm not sure if I would want to 'just leave them off' though.
I was thinking more along the lines of this one, but leaving the meta layer of W-T, A-H and Z-M unprinted.Trying to keep track of _wb_'s layouts is like herding cats.Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)
By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.
One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.
So what you would like is something like this with the non-English characters in the Fn layer not printed?
http://www.keyboard-layout-editor.com/#/layouts/467f092b9169fe6c6b411baa5a39beeb
Yeah, I'd say that sounds like a good basis for the default assignments for those keys.That makes sense, too. But why not provide a default that works well for English, French and German (the three languages specifically mentioned by ED), and do the rest with software as you describe?
I can live with that layout - it is very similar to the one I posted in the above example.I was thinking more along the lines of this one, but leaving the meta layer of W-T, A-H and Z-M unprinted.
Why not provide a default that works even better for English, French and german, and do the rest as per described? That is the compromise.That makes sense, too. But why not provide a default that works well for English, French and German (the three languages specifically mentioned by ED), and do the rest with software as you describe?Personally, I still think that most of the symbols not found on a US-Qwerty keyboard should be hidden, not because of clutter, but to allow different predefined national layouts that modify a selection of otherwise undefined keys in the meta shift+meta layers with an optimal layout for that specific language. (with software to display the relevant keymaps (and switch them) when needed)
By putting _+{}|:"? on the shift+meta layer, it would maximise the area available for localisation.
One of _wb_'s earlier "DosBOX Compatible" layouts would probably make a good multi-lingual default for those keys for users who don't have any specific non-English language requirement.
- Neelix
I should think language is more important to the target demographic than symbols. Maybe we should ask the userbase if greek and extra math provisions are wanted too.wb said:PERFECT: All commonly used letters are available as primary keys
Having those characters printed wouldn't bother me much in and of itself. As I've said before, I'm not terribly concerned about visual clutter.Is the non-English set something that would truly bother you to have on the device? Or is it something you could just, 'ignore and move on'? I'm pretty sure I could just ignore the characters I don't need. They are not particularly obtrusive. Since they're all on the left 2/3 of the keyboard, I can simply ignore the orange writing on that zone and be good with it. I.e. they're contained in one area to the left and the English Fn characters are on the right. Easy.
Multiple layouts can break positional key bindings (key bindings chosen because of their absolute or relative position on the keyboard) . See example in my previous post. Because of this I think the primary key functions should be the same in all layouts, if there are multiple.Having those characters printed wouldn't bother me much in and of itself. As I've said before, I'm not terribly concerned about visual clutter.Is the non-English set something that would truly bother you to have on the device? Or is it something you could just, 'ignore and move on'? I'm pretty sure I could just ignore the characters I don't need. They are not particularly obtrusive. Since they're all on the left 2/3 of the keyboard, I can simply ignore the orange writing on that zone and be good with it. I.e. they're contained in one area to the left and the English Fn characters are on the right. Easy.
It's just that the idea of of having multiple good keymaps with no conflicting symbol information on the keys (as opposed to just one all-inclusive layout with a lot of compromises) really appeals to me.
- Neelix
True, but a blank keymat also fits that description. User remapping, even with a practical tool that shows what each Meta-key does on the screen when you hold down Meta, still introduces an extra translation step from the screen or user memory to the physical keyboard. Labels that are printed on the keys themselves are still a more direct way (though obviously less flexible) to convey the information.Having those characters printed wouldn't bother me much in and of itself. As I've said before, I'm not terribly concerned about visual clutter.Is the non-English set something that would truly bother you to have on the device? Or is it something you could just, 'ignore and move on'? I'm pretty sure I could just ignore the characters I don't need. They are not particularly obtrusive. Since they're all on the left 2/3 of the keyboard, I can simply ignore the orange writing on that zone and be good with it. I.e. they're contained in one area to the left and the English Fn characters are on the right. Easy.
It's just that the idea of of having multiple good keymaps with no conflicting symbol information on the keys (as opposed to just one all-inclusive layout with a lot of compromises) really appeals to me.
- Neelix
My intention was always to have a static primary layer and static US-keyboard key equivalents on the meta layer. That's what would be printed on the keys. It would only be the meta layer of a specific subset of keys that would change between layouts.Multiple layouts can break positional key bindings (key bindings chosen because of their absolute or relative position on the keyboard) . See example in my previous post. Because of this I think the primary key functions should be the same in all layouts, if there are multiple.
What happens behind modifiers mainly affects software that expect certain shift-pairs as has been said here before. I consider this a lesser issue though, because key bindings rarely depend on what symbol comes out of X using a modifier.
True, but a blank keymat also fits that description. User remapping, even with a practical tool that shows what each Meta-key does on the screen when you hold down Meta, still introduces an extra translation step from the screen or user memory to the physical keyboard. Labels that are printed on the keys themselves are still a more direct way (though obviously less flexible) to convey the information.
The point is to optimise the dynamic area for specific languages. That might mean putting certain letters at different places to where you would put them in the default combined layout. If you have them printed somewhere other than where they are mapped that creates confusion.I think your approach is a good idea for the AltGr layer, which is completely unlabeled in most proposals and thus fully user-configurable. For the Meta layer I prefer actual printed symbols for German, French and some diacritics. That covers most languages well enough imo. For languages like Polish or Norwegian you still have to use the AltGr layer. There don't have to be conflicting labels with that approach.
Depends what kind of information you convey. A layout is already in muscle memory, not in knowledge. Adding a different than usual visual layout, is a serious de-tour. Meta layer is only good enough for interlingual use. I dont understand what polish or Norwegian has to do with AltGr.True, but a blank keymat also fits that description. User remapping, even with a practical tool that shows what each Meta-key does on the screen when you hold down Meta, still introduces an extra translation step from the screen or user memory to the physical keyboard. Labels that are printed on the keys themselves are still a more direct way (though obviously less flexible) to convey the information.Is the non-English set something that would truly bother you to have on the device? Or is it something you could just, 'ignore and move on'? I'm pretty sure I could just ignore the characters I don't need. They are not particularly obtrusive. Since they're all on the left 2/3 of the keyboard, I can simply ignore the orange writing on that zone and be good with it. I.e. they're contained in one area to the left and the English Fn characters are on the right. Easy.
Having those characters printed wouldn't bother me much in and of itself. As I've said before, I'm not terribly concerned about visual clutter.
It's just that the idea of of having multiple good keymaps with no conflicting symbol information on the keys (as opposed to just one all-inclusive layout with a lot of compromises) really appeals to me.
- Neelix
I think your approach is a good idea for the AltGr layer, which is completely unlabeled in most proposals and thus fully user-configurable. For the Meta layer I prefer actual printed symbols for German, French and some diacritics. That covers most languages well enough imo. For languages like Polish or Norwegian you still have to use the AltGr layer. There don't have to be conflicting labels with that approach.
For Scandinavians, an US-International AltGr layer suffices to cover their Å Æ Ø Ä Ö (and even Þ and Ð) : http://en.wikipedia.org/wiki/AltGr_key#US-InternationalDepends what kind of information you convey. A layout is already in muscle memory, not in knowledge. Adding a different than usual visual layout, is a serious de-tour. Meta layer is only good enough for interlingual use. I dont understand what polish or Norwegian has to do with AltGr.
But an AltGr layer gives you the biggest possible "dynamic area", since every single key is available: all letters, all numbers, all punctuation symbols, etc. Take the example of Polish:I think your approach is a good idea for the AltGr layer, which is completely unlabeled in most proposals and thus fully user-configurable. For the Meta layer I prefer actual printed symbols for German, French and some diacritics. That covers most languages well enough imo. For languages like Polish or Norwegian you still have to use the AltGr layer. There don't have to be conflicting labels with that approach.
The point is to optimise the dynamic area for specific languages. That might mean putting certain letters at different places to where you would put them in the default combined layout. If you have them printed somewhere other than where they are mapped that creates confusion.
- Neelix