It's the keyboard layout.

[ekianjo]

tilda, underscore and curly brackets all Three keys cOmbos, man you must hate the command lIne and programmIng In general.

 

[_wb_]

Here is my most recent and currently best-scoring keyboard layout proposal:




The dedicated German keys ü ä ö ß are all there (at ◆YUHB).

The dedicated French keys é è ç à are all there (at ◆SDCV).

The dedicated Spanish keys ñ ¿¡ are all there (at ◆NQ).

The dedicated Portuguese key ç is there (at ◆C).

The dedicated Swedish/Finnish keys å ö ä are all there (at ◆THY).

The dedicated Danish/Norwegian keys å æ ø are all there (at ◆TFG).

The Euro sign € is there (at ◆E).

The British pound sign £ is there (at ◆R).

It supports all the important diacritics:

• acute ´ as a mashable combo at ◆'                          to get e.g. áéíúó      (é is already available precomposed)
• umlaut ¨ as a mashable combo at ◆"  (Shift+◆')      to get e.g. äëïöü      (äöü are already available precomposed)
• grave ` as a mashable combo at ◆A                        to get e.g. àèìòù      (àè are already available precomposed)
• tilde ~ as a maybe-mashable combo at Shift+◆A     to get e.g. ñãõ         (ñ is already available precomposed)
• cedilla/ogonek/comma ¸ at ◆,                                   to get e.g. çşąęįųşţ  (ç is already available precomposed)
• caron/háček/breve at ◆<                                          to get e.g. čšž ěăğ
• underdot/overdot/ring at ◆.                                      to get e.g. ċėżıåů      (å is already available precomposed)
• circumflex ^ at ◆>                                                     to get e.g. âêîôû

This implies that a.o. French, Spanish, Portuguese, Dutch, Italian, Irish, Slovakian, Turkish, Estonian, Czech, Bosnian, Croatian, Serbian, Slovenian and Romanian are fully covered; Polish, Latvian, Lithuanian, Hungarian and Maltese are mostly covered but would still need some minor adjustments, i.e. remappings to get Ł, ū, macron, őű and ħ respectively.

Out of the 24 official languages of the European Union, only Greek and Bulgarian are not supported, and that's because they don't use a Latin-based alphabet.

More important languages in terms of number of speakers, number of native speakers, and "sales potential" have been given priority over less important languages by including more of their language-specific letters on the keymat.

So in my opinion, this is a very nice proposal. For the major languages (English, Spanish, Portuguese, German, French, Italian) and also for the Scandinavian languages and Dutch, you have all the letters that are a dedicated key on your regional keyboard available as either a primary key or as a labeled ◆ key -- if you're using the shoulder buttons, it's only one thumb press per letter. I think that's about as good as it gets in terms of international/multilingual support.

 

[_wb_]

tilda, underscore and curly brackets all Three keys cOmbos, man you must hate the command lIne and programmIng In general.

They're not, at least not in Saber's proposal which I think you were referring to. E.g. he has underscore at Fn+Shift+E (unlabeled), but also more directly at Fn+T (labeled).

In my proposal, ~ _ { } + : " | ? < > are indeed at Shift+` - [ ] = ; ' \ / , .  (just like on a regular US-QWERTY keyboard), which means that some of them are behind Meta+Shift.

I have ' , . as primary keys, so " < > are just Shift+ ' , . , and I also have the 'numpad' + and - as primary keys, so " < > - + are easy enough (just one or zero modifiers).

But that still leaves  ~ _ { } : | ?, which are only available as Meta+Shift keys.

So yes, that is a (minor) inconvenience of this proposal. On the other hand, I have Meta and Shift right next to one another, so it should be relatively easy to chord both of them with the left thumb, while hitting the symbol key with the right thumb. Also if you use the shoulder button method, L1+L2 should be not too hard to do (I hope!).

 

[Saber]

tilda, underscore and curly brackets all Three keys cOmbos, man you must hate the command lIne and programmIng In general.

They're not, at least not in Saber's proposal...

Thanks for that. :wub:

You'd think all the comprehensive attention we infuse our layouts with that members would take time to actually read through carefully instead of skim them. Geez.  :lol:

 

[comradekingu]

wb:

That means there is a double-chorded action+key for both language _and_ terminal/coding. I think you stared yourself blind at the pairs part of US convention.

You almost have position, but there arent enough keys to do that. You end up with the US international dead-keys on more than each their own letter.

With a fuller layout you could have had position for some things, and you would also get the arrangement. Regularpress and shift+

I am suggesting the ability to differentiate between F-keys and and non-shift symbols on the number row is better than having a partial way of doing keypairs for half the market. (US)

I dont think losing the euros over pleasing the US slightly more, if that is the case, is good.

You can then get 

¿¡ back on numberrow.

£ away from R and onto L or P

The same invoker for all dead-keys

´ and " wouldnt have to be a key on the left

shift could be correct side

F11 and F12 wouldnt have to be relegated to bottom row

, and . wouldnt have to be stepped

< and > wouldnt have to be stepped

Get the ¥ symbol on Y, move ß to S where it is expected

You could then argue its not needed to see all the foreign letters, which isnt ideal to begin with. Certainly not for the english users you set out to please with the pairs.

Not have to do scandinavian and old-english letters.

There wouldnt have to be what is essentially 4 slots per key with 3 prints.

If the big letter is in the middle (like K), then you are making it 4slotted if you put meta + ] and shift+meta } on the right of it.

Otherwise there is an inconsitency with the letters, because there the number is in the middle.

And/or not have to do colours, which looks worse and is more costly.

 

[_wb_]

wb:

That means there is a double-chorded action+key for both language _and_ terminal/coding. I think you stared yourself blind at the pairs part of US convention.

Well yes, : and ? are behind Shift+Meta+L ( Shift+; ) and Meta+Shift+space ( Shift+/ ) in my proposal, but considering the location of my Meta and Shift, I'd say that's not a big issue.

By contrast, in your proposal, you have : and ? at Shift+[right side of a wobbly space] and at AltGr+6, respectively. The first is a maneuver that involves avoiding Enter while mashing Shift with part of the space bar (like Enter+Space on the Pandora); the second looks rather unpleasant to me (like Pandora-button+T or something). Yes, it's only one modifier, but still I don't think those are really easier than what I'm proposing. Provided you even know where to look for those symbols, because Shift+Space and AltGr+6 are not really the first things that spring to mind when thinking about : and ?.

 

[Grench]

Here is my most recent and currently best-scoring keyboard layout proposal:

wb_intl2.png

The dedicated German keys ü ä ö ß are all there (at ◆YUHB).

The dedicated French keys é è ç à are all there (at ◆SDCV).

The dedicated Spanish keys ñ ¿¡ are all there (at ◆NQ).

The dedicated Portuguese key ç is there (at ◆C).

The dedicated Swedish/Finnish keys å ö ä are all there (at ◆THY).

The dedicated Danish/Norwegian keys å æ ø are all there (at ◆TFG).

The Euro sign € is there (at ◆E).

The British pound sign £ is there (at ◆R).

It supports all the important diacritics:

• acute ´ as a mashable combo at ◆'                          to get e.g. áéíúó      (é is already available precomposed)
• umlaut ¨ as a mashable combo at ◆"  (Shift+◆')      to get e.g. äëïöü      (äöü are already available precomposed)
• grave ` as a mashable combo at ◆A                        to get e.g. àèìòù      (àè are already available precomposed)
• tilde ~ as a maybe-mashable combo at Shift+◆A     to get e.g. ñãõ         (ñ is already available precomposed)
• cedilla/ogonek/comma ¸ at ◆,                                   to get e.g. çşąęįųşţ  (ç is already available precomposed)
• caron/háček/breve at ◆<                                          to get e.g. čšž ěăğ
• underdot/overdot/ring at ◆.                                      to get e.g. ċėżıåů      (å is already available precomposed)
• circumflex ^ at ◆>                                                     to get e.g. âêîôû

This implies that a.o. French, Spanish, Portuguese, Dutch, Italian, Irish, Slovakian, Turkish, Estonian, Czech, Bosnian, Croatian, Serbian, Slovenian and Romanian are fully covered; Polish, Latvian, Lithuanian, Hungarian and Maltese are mostly covered but would still need some minor adjustments, i.e. remappings to get Ł, ū, macron, őű and ħ respectively.

Out of the 24 official languages of the European Union, only Greek and Bulgarian are not supported, and that's because they don't use a Latin-based alphabet.

More important languages in terms of number of speakers, number of native speakers, and "sales potential" have been given priority over less important languages by including more of their language-specific letters on the keymat.

So in my opinion, this is a very nice proposal. For the major languages (English, Spanish, Portuguese, German, French, Italian) and also for the Scandinavian languages and Dutch, you have all the letters that are a dedicated key on your regional keyboard available as either a primary key or as a labeled ◆ key -- if you're using the shoulder buttons, it's only one thumb press per letter. I think that's about as good as it gets in terms of international/multilingual support.

This one is very good.   Lots of positives.

Language support is excellent.  Ignore CK.  He'll never be satisfied by anything but his own proposal.  I see you went with Fn level dedicated dead keys.  That should work well.  However, doesn't that negate the need for dedicated non-English symbols on the Fn layer of the keyboard?

Ä is on H.  To get to it requires Fn+H.

Ä is also on Fn+Shift+' then A.

It isn't a bad thing, just a redundant thing.  Fn+H is somewhat easier to hit than Fn+Shift+' then A.

The layout matrix rewards having dedicated keys for German and French and the presence of diacritics, despite the fact that they're two ways of treating the same problem.

If the clutter police come after you for "Too many weird keys on my keyboard that I don't understand because I live in a bubble!", maybe consider eliminating dedicated for just diacritic?  Though it would be a  step backwards. 

DosBox support, pairing US standard symbols is excellent.   Thank you again for coming around on this.

You have MANY MANY layouts that have progressed far from your original ideas.  Yet you still lay claim to a 'Main' one that is, quite frankly in my humble opinion, a disaster by comparison.  Where do you sit on your own layouts?  Which one of your own layouts do you think is currently the 'best'?

 

[_wb_]

Here is my most recent and currently best-scoring keyboard layout proposal:

wb_intl2.png


The dedicated German keys ü ä ö ß are all there (at ◆YUHB).


The dedicated French keys é è ç à are all there (at ◆SDCV).


The dedicated Spanish keys ñ ¿¡ are all there (at ◆NQ).


The dedicated Portuguese key ç is there (at ◆C).


The dedicated Swedish/Finnish keys å ö ä are all there (at ◆THY).


The dedicated Danish/Norwegian keys å æ ø are all there (at ◆TFG).


The Euro sign € is there (at ◆E).


The British pound sign £ is there (at ◆R).


It supports all the important diacritics:

• acute ´ as a mashable combo at ◆'                          to get e.g. áéíúó      (é is already available precomposed)
• umlaut ¨ as a mashable combo at ◆"  (Shift+◆')      to get e.g. äëïöü      (äöü are already available precomposed)
• grave ` as a mashable combo at ◆A                        to get e.g. àèìòù      (àè are already available precomposed)
• tilde ~ as a maybe-mashable combo at Shift+◆A     to get e.g. ñãõ         (ñ is already available precomposed)
• cedilla/ogonek/comma ¸ at ◆,                                   to get e.g. çşąęįųşţ  (ç is already available precomposed)
• caron/háček/breve at ◆<                                          to get e.g. čšž ěăğ
• underdot/overdot/ring at ◆.                                      to get e.g. ċėżıåů      (å is already available precomposed)
• circumflex ^ at ◆>                                                     to get e.g. âêîôû

This implies that a.o. French, Spanish, Portuguese, Dutch, Italian, Irish, Slovakian, Turkish, Estonian, Czech, Bosnian, Croatian, Serbian, Slovenian and Romanian are fully covered; Polish, Latvian, Lithuanian, Hungarian and Maltese are mostly covered but would still need some minor adjustments, i.e. remappings to get Ł, ū, macron, őű and ħ respectively.
Out of the 24 official languages of the European Union, only Greek and Bulgarian are not supported, and that's because they don't use a Latin-based alphabet.


More important languages in terms of number of speakers, number of native speakers, and "sales potential" have been given priority over less important languages by including more of their language-specific letters on the keymat.


So in my opinion, this is a very nice proposal. For the major languages (English, Spanish, Portuguese, German, French, Italian) and also for the Scandinavian languages and Dutch, you have all the letters that are a dedicated key on your regional keyboard available as either a primary key or as a labeled ◆ key -- if you're using the shoulder buttons, it's only one thumb press per letter. I think that's about as good as it gets in terms of international/multilingual support.

 
This one is very good.   Lots of positives.


Language support is excellent.  Ignore CK.  He'll never be satisfied by anything but his own proposal.  I see you went with Fn level dedicated dead keys.  That should work well.  However, doesn't that negate the need for dedicated non-English symbols on the Fn layer of the keyboard?


Ä is on H.  To get to it requires Fn+H.


Ä is also on Fn+Shift+' then A.


It isn't a bad thing, just a redundant thing.  Fn+H is somewhat easier to hit than Fn+Shift+' then A.


The layout matrix rewards having dedicated keys for German and French and the presence of diacritics, despite the fact that they're two ways of treating the same problem.


If the clutter police come after you for "Too many weird keys on my keyboard that I don't understand because I live in a bubble!", maybe consider eliminating dedicated for just diacritic?  Though it would be a  step backwards. 


DosBox support, pairing US standard symbols is excellent.   Thank you again for coming around on this.

Thanks, Grench.


The diacritics are not redundant, since the dedicated precomposed accented letters are not enough to cover everything by themselves, they're just the letters that are used frequently enough to deserve a dedicated (Meta) key. For example, for French, you also need circumflex (âêîôû) and ù, but more rarely than éèàç: e.g. ù is only used specifically in the word "où" (which means "where", and is a different word than "ou" which means "or"). So no need to have ù labeled, but you still need to be able to type it. In many languages you need acutes on other vowels than just é, and e.g. in Italian you need graves on any vowel (àèìòù); in Portuguese you need tildes on A and O (ãõ), in Dutch and French you need diaeresis on E and I (ëï), and so on.


Having only the diacritic keys would look somewhat cleaner, but then again having dedicated keys is more efficient for the languages that use them a lot. Also e.g. Scandinavian languages don't really consider ä ö as "umlauted a" and "umlauted o", but they're letters on their own. A bit like we don't consider J as an "letter I with a hook diacritic below" or W as two V's (or two U's), even though that's their origin. And dead diacritics don't really help for Æ ß Å Ø  and also not for the symbols ¿ ¡ § ° € £. So if we're gonna label some "foreign" stuff anyway, then better make sure that all languages can be typed as efficiently as possible.

You have MANY MANY layouts that have progressed far from your original ideas. Yet you still lay claim to a 'Main' one that is, quite frankly in my humble opinion, a disaster by comparison. Where do you sit on your own layouts? Which one of your own layouts do you think is currently the 'best'?

You can find my own preferences on row 100 of the big comparison table

Assuming double-width space is obligatory, "_wb_ intl 2"  is currently my favorite.

The table (which was your idea, btw) has actually helped me to improve my proposals. I only wish more people would specify their priorities/weights.

 

[Urben]

The table (which was your idea, btw) has actually helped me to improve my proposals. I only wish more people would specify their priorities/weights.

Maybe if ED would mention it at the next news with a direct link to it there would be more feedback.

 

[ible]

I'm not a big fan of _wb_ intl2 getting by with reduced weights for putting labels on keys, and a few other things...  Do you mind if I make a few changes based on that and the PM, _wb_?

It is sad to see fewer people adding their priorities in (thanks btw Urben), but it's also hard when the matrix is changing so much .  You have to go back to make sure your favorites are still in order!

 

[comradekingu]

Language support is excellent. Ignore CK. He'll never be satisfied by anything but his own proposal.

How many of the languages that use those letters do you speak Grench? Since your opinion matters, and mine doesnt, lets first establish that.


The latter part of your assumption seems to disregard arguments in favour of your straw-man argument. Considering i did post a valid argument, you are saying i cant have an opinion nor can my arguments be valid, because i accounted for them in making my layout.


Why wouldnt that be the case?


I have issues understanding how you arent sure if the ability to press three-chorded combos negate the need for two-corded combos,


and how this whole ordeal can continue to be excellent?

What do you call a regular keyboard, where some of those letters are dedicated? Over-excellent? Extra-excellent?


If your language support only is a regard for ability and not functionality in terms of efficiency and habit, aka actual use, then why dont we get a num-lock so we can get


ALT-codes. No need for any symbols, or letters, just need the numbers and you will have glorious language-support.

What good is language support if you dont cater to an international audience? As in native spearkers of said language.

wb:


That means there is a double-chorded action+key for both language _and_ terminal/coding. I think you stared yourself blind at the pairs part of US convention.

 
Well yes, : and ? are behind Shift+Meta+L ( Shift+; ) and Meta+Shift+space ( Shift+/ ) in my proposal, but considering the location of my Meta and Shift, I'd say that's not a big issue.


By contrast, in your proposal, you have : and ? at Shift+[right side of a wobbly space] and at AltGr+6, respectively. The first is a maneuver that involves avoiding Enter while mashing Shift with part of the space bar (like Enter+Space on the Pandora); the second looks rather unpleasant to me (like Pandora-button+T or something). Yes, it's only one modifier, but still I don't think those are really easier than what I'm proposing. Provided you even know where to look for those symbols, because Shift+Space and AltGr+6 are not really the first things that spring to mind when thinking about : and ?.

Its more the concept i have a problem with. Something-other-than-AltGr+letter is already something that fails for new users. Shift+something-other-than-AltGr+letter is a concept we shouldnt rely on. Because regular layouts dont rely on shift+AltGr, users arent used to it. Nor do i think putting often used things behind it is efficient.


Its a question of what you would rather do, combo-press something, or have the option not to and use two hands. Or having to combo press something, and use the other hand aswell.


One is a whole lot more efficient than tying up both thumbs. Using both thumbs on one side of the keyboard or combo-pressing to get the key directly is as good as it gets.


Other options only result in less direct-presses, moving all keys around and not having numbers, or messing up US shift-row convention.


I agree the space is dumb, I just think thats the best way of doing a non-centered non-stabelized dualwide space, if ED insists on doing it. Its possible to have the exact same layout without it, meaning a dualwide space that does only one thing, but it makes the keyboard less efficient.

http://www.keyboard-layout-editor.com/#/layouts/7e81eec1ad02e9be1ff546537db1d32b and http://www.keyboard-layout-editor.com/#/layouts/67a13079322178cefb45cd394ade6e03 have a lot of the ideas i mentioned.

 

[bzar]

I just modified my proposal based on some good feedback from a forum member (I'll reveal the identity if he wishes to take credit ). Namely it was about the location of SysRq being on Fn+[Letter]. I just moved it to Fn+Backspace to make it possible to press SysRq with any letter key. Got me wondering though: SysRq is basically a modifier key interpreted by the kernel. Having a modifier behind a modifier is bad news for combos with multiple modifiers. If SysRq is Fn+[Anything], we can't do SysRq+Fn+[Anything] combos. More importantly, if we press Fn+[something that produces SysRq with Fn]+[something that also has an Fn combo], which of the two Fn-enabled keys gets the Fn-modification? Is it based on order? Both?
 

On some laptops, SysRq is accessible only by pressing Fn. In this case, the combination is a bit trickier: hold Alt, hold Fn, hold SysRq, release Fn, press desired letter key or keys. Or, on some newer laptops, press and hold Fn+Alt (and also Ctrl if using X11/XWindows and not a text console) and then press and hold SysRq and then press the desired letter keys. (The order of pressing and holding Fn, Alt and Ctrl doesn't matter, but those keys must be already held down before pressing and holding SysRq and then press and release the desired letter key).

This sounds complex and is somewhat opposed to Fn being handled like an additive modifier (like the other modifiers, where the order of pressing them doesn't matter).

I'm quite sure this issue is with any layout that implements SysRq as anything other than its own primary key. I see four alternatives:

1. Ditch the SysRq key. It's not used that much and in many distributions its primary functions are disabled by default.

Give SysRq its own key. Do not want. We are low enough on keyboard real estate as it is.
Accept the possible conflicts in modifier combos, carry on as usual.
Make SysRq sticky and make the whole problem go away.
The last one seems the most sensible. Thoughts?

 

[comradekingu]

1.

Drop SysRq and let those who need it figure out a way to hack it in. For every few users that need sysRq, you confuse the remainder of the potential usergroup.

It makes it look needlessly technical, it makes it look cramped. If not cramped, you are wasting a key on SysRq, which isnt even done on 105key.

 

[dimag0g]

tilda, underscore and curly brackets all Three keys cOmbos, man you must hate the command lIne and programmIng In general.

They're not, at least not in Saber's proposal which I think you were referring to. E.g. he has underscore at Fn+Shift+E (unlabeled), but also more directly at Fn+T (labeled).

What sense does it make to have two combinations for these keys then?

 

[Saber]

tilda, underscore and curly brackets all Three keys cOmbos, man you must hate the command lIne and programmIng In general.

They're not, at least not in Saber's proposal which I think you were referring to. E.g. he has underscore at Fn+Shift+E (unlabeled), but also more directly at Fn+T (labeled).

What sense does it make to have two combinations for these keys then?

DOSBox and QEMU. On Pandora, they won't register Fn + . for : symbol. Others as well.

You'd need to press Shift + Fn + ; for : instead to get it to work: http://pandorawiki.org/DOSBox#Keyboard

Please review my layout again as I've noticed you also, as ekianjo has, failed to grasp { } and more are duplicated for these programs but are available at the Fn + standard level. I even color coded it to help.

 

[Saber]

1.


Drop SysRq and let those who need it figure out a way to hack it in. For every few users that need sysRq, you confuse the remainder of the potential usergroup.


It makes it look needlessly technical, it makes it look cramped. If not cramped, you are wasting a key on SysRq, which isnt even done on 105key.

SysRq by itself does nothing. Combo it with Alt and you open a wide world of low-level MagicSysRq commands. Even though some people wanted it, it may not end up in the final layout, but some see the value in including it(if it can be).  

 

[comradekingu]

A lot of people want a lot of different things.

So lets assume its impossible to make dosbox accept other layouts, contrary to what its manual says.

Would the demand for that warrant a custom run of keymats?

What special game or program is it that needs the level of either US pairs or position each layout claiming to be so works with?

If no, then what is it doing in what i understand to be the main default layout?

Pleasing anyone at the cost of general writing and coding, what audience for a keyboard are you then left to satisfy?

 

[Saber]

A lot of people want a lot of different things.

So lets assume its impossible to make dosbox accept other layouts, contrary to what its manual says.

Would the demand for that warrant a custom run of keymats?

What special game or program is it that needs the level of either US pairs or position each layout claiming to be so works with?

If no, then what is it doing in what i understand to be the main default layout?

Pleasing anyone at the cost of general writing and coding, what audience for a keyboard are you then left to satisfy?

Are you saying we should commit to nothing because we can't please everyone? 

 

[_wb_]

I'm not a big fan of _wb_ intl2 getting by with reduced weights for putting labels on keys, and a few other things...  Do you mind if I make a few changes based on that and the PM, _wb_?

It is sad to see fewer people adding their priorities in (thanks btw Urben), but it's also hard when the matrix is changing so much .  You have to go back to make sure your favorites are still in order!

OK, fixed that. I did reduce the count for the labels for éèàçäüö etc (by counting them only as "half" an extra label) because the idea is that those extra labels would be in a smaller/thinner font so they would not distract too much. But in a sense that is cheating, so I went back to fully counting them (which means that people who give negative weight to "clutter" give it a lower score now, e.g. it is no longer your top proposal now, ible

I also added the following property:

"German-centric": supports German but not other languages

because we already had a property "German letters labeled (ÄÖÜß)" which I originally gave a negative weight myself, until I started producing proposals that actually have the German letters labeled

My reasoning is as follows: I don't really mind that the German letters (or letters for whatever other language) are labeled (besides for the clutter that it adds, but that is already taken into account elsewhere), but I do mind having a keyboard that looks like it is made for another language/locale than my own or just US-QWERTY. So I don't like a "German-centric" layout (or a "Spanish-centric" layout, or whatever other language), but I do like a layout that either shows no "international" stuff at all, or it has "international" stuff but in a general way, not favoring one specific language like German.

So now I give a positive weight to "German letters labeled" (and also positive weights to the other languages), but a negative weight to "German-centric". In other words: I don't mind äöüß being labeled, as long as éèàçñ¿¡åæø′¸`.¨~ˆˇ are also labeled. I don't know if that makes sense to you guys

Here's the link to the big table again, for convenience: https://docs.google.com/spreadsheets/d/14mVNNzLhmhyA4sCIAPSoDv404xtctfLSiEMTtTlEzfw/edit?usp=sharing

 

[ible]

Thanks .  Yeah I have almost no preference on intl characters, since I wouldn't need them.