It's the keyboard layout.

[comradekingu]

I like it more because you see less of things out of place.

Like your thinking.  Just sand down the keys very gently, and put overlays on what you need.

Actually thats a bit junk, but sanding down the keys to full transparent would work if they arent doubleshot all the way through.

 

[_wb_]

Really, remembering AltGr + i was ß in my keyboard but is now remapped to ç should be just as easy to recall as AltGr + i was blank but is now ç.

Yes, remembering should be just as easy. Though AltGr/Meta + c = ç is easier to remember than AltGr + i = ç

The point is though that incomplete labels are strictly better than incorrect ones.

I like it more because you see less of things out of place.

Like your thinking.  Just sand down the keys very gently, and put overlays on what you need.

Actually thats a bit junk, but sanding down the keys to full transparent would work if they arent doubleshot all the way through.

There would be no need to sand down if you just want to add Meta labels to keys that have no Meta labels yet. It would of course be necessary if you want to completely change the layout.

 

[ible]

Here's a more consolidated (Grench'ified) meta/shift on the right keyboard:

http://www.keyboard-layout-editor.com/#/layouts/b4c72dbbddac3d92972d0d635cdf1f62

this still keeps +=, -=, >=, and /= as quick coding combos.

 

[Saber]

Really, remembering AltGr + i was ß in my keyboard but is now remapped to ç should be just as easy to recall as AltGr + i was blank but is now ç.

Yes, remembering should be just as easy. Though AltGr/Meta + c = ç is easier to remember than AltGr + i = ç

The point is though that incomplete labels are strictly better than incorrect ones.

Incomplete isn't the same as blank and å and ä cannot both be on A. There isn't so many keys that even the most absentminded multilinquist would have issue remembering where they remapped their symbols and characters to which button, and I would prefer those places be for more important ~_`{things}?-:=|+ 

 

[Neelix]

Incomplete isn't the same as blank and å and ä cannot both be on A. There isn't so many keys that even the most absentminded multilinquist would have issue remembering where they remapped their symbols and characters to which button, and I would prefer those places be for more important ~_`{things}?-:=|+ 

Thing is, if we're going to have accented letters with their own keys then we are going to *have* to be able to combine AltGR and Shift anyway, so that if (for example) á is mapped to AltGR+A then Á would need to be on AltGR+Shift+A
That being the case it also makes sense to put the shifted symbols on the keyboard *as* shifted symbols, as 1) it would mean less customisation needs to be done to get the keyboard layouts right and 2) it means we have a lot more available space for internationalisation, and could offer optimised layouts for each language.

- Neelix

 

[comradekingu]

Or just have a real AltGr (and/or ^), since that is part of what it does.

 

[Grench]

With your keyboard if I want to make « ê » I press shift+6 in order to have the « ^ » and the key « e » right ?

No, Shift-6 just gives ^ as an ascii character. You can press Compose, then Shift-6 and "e" to get "ê", but that's a bit cumbersome. That's why if you often need circumflexes, it's better to have a dead circumflex somewhere (e.g. Meta+V or Meta+ B) , or even map precomposed circumflex letters, e.g. you could map éêè to Meta+WER for optimal efficiency.

Here's my proposal, with the default mapping indicated in a darker shade of the auxiliary color:

http://www.keyboard-layout-editor.com/#/layouts/86df760fd41803365c8390943101d4e1

It has dead circumflex at Meta+B (for âêîôû) and dead caron at Meta+V (for čšžřňľěǧȟŤĎ). The caron is quite important for the Balto-Slavic languages, so it makes sense to have it too.

I think that the idea of two shades of the alternate color to de-emphasize the 'weird foreign stuff' might be a good solution to tone down the 'English only!' crowd.  I.e. you may have a good compromise there.

What about this?

http://www.keyboard-layout-editor.com/#/layouts/64853e8adc980fcb80fd1eaff4e185e9

Comradekingu and Grench and probably others have proposed a similar thing in the past. Use an inverted color scheme where most of the button is transparent and only the label gets ink.

Main advantages:

• It becomes possible to add labels to the keys, by printing an overlay on some kind of transparent plastic sheet, or simply by using a suitable pen and manually writing stuff at the bottom of the keymat. Ultimate physical customability!
• Less backlight brightness is required, saving some power

Main disadvantage:

• This color scheme might look cheap or weird.

Additional benefits...

No light leakage at key edges - which can be annoying on a black-key negative print keyboard (see Sony Vaio backlights).

Black Key edges -will- get their black paint scratched on the frame over time and have light sneak through.

Uncoated key edges/sided will be less likely to show wear.

May trim production costs a bit - mats only get printed on key tops and not on the sides of every key.  Less ink/dye used.

Keyboard backlight could more readily be used as an 'inaudible alarm' function without having to power up the LCD.

Symbols could be printed in 'translucent' colors instead of using only black (inked) and white (non-inked).

Secondary/tertiary symbols will appear clearer even when using smaller fonts.

Black/color text in small fonts on a white background is easier to read than white/color text in small fonts on a black background.

But, yes, it looks a bit different.  Different is good.

 

[Xcl4m4t10n]

Can anybody make a summary of what have you been discussing or if we have a more or less conclussion? Thank you in advance .

 

[Christoph.Krn]

Can anybody make a summary of what have you been discussing or if we have a more or less conclussion? Thank you in advance .

There are too many important details for a short-ish summary, but I guess that the important information is that there is actual progress.

 

[rygD]

Comradekingu and Grench and probably others have proposed a similar thing in the past. Use an inverted color scheme where most of the button is transparent and only the label gets ink.

AAAHHHHH, MY EYES!!! SO BRIGHT!  I  know it won't really blind my very light sensitive eyes.  I am not totally against it.  I do find it undesirable if the cap can be colored with only the characters translucent.  The keyboard LEDs probably won't be brighter than the display, but it has happened before on other devices, and it is irritating.

 

[Grench]

Comradekingu and Grench and probably others have proposed a similar thing in the past. Use an inverted color scheme where most of the button is transparent and only the label gets ink.

AAAHHHHH, MY EYES!!! SO BRIGHT!  I  know it won't really blind my very light sensitive eyes.  I am not totally against it.  I do find it undesirable if the cap can be colored with only the characters translucent.  The keyboard LEDs probably won't be brighter than the display, but it has happened before on other devices, and it is irritating.

Easy albeit insensitive solution to keyboard back-light sensitivity.

Bight, normal, dim, dimmer, dimmest, off.

 

[Saber]

Incomplete isn't the same as blank and å and ä cannot both be on A. There isn't so many keys that even the most absentminded multilinquist would have issue remembering where they remapped their symbols and characters to which button, and I would prefer those places be for more important ~_`{things}?-:=|+ 

Thing is, if we're going to have accented letters with their own keys then we are going to *have* to be able to combine AltGR and Shift anyway, so that if (for example) á is mapped to AltGR+A then Á would need to be on AltGR+Shift+A

That being the case it also makes sense to put the shifted symbols on the keyboard *as* shifted symbols, as 1) it would mean less customisation needs to be done to get the keyboard layouts right and 2) it means we have a lot more available space for internationalisation, and could offer optimised layouts for each language.


- Neelix

Actually it doesn't make much sense to put the normally shifted values like ? or { only under AltGr + Shift like some of these proposals attempt to do. One AltGr + key for symbol is fewer "steps" than AltGr + Shift + key. The selective handful of these marks which are known to not play nice with DOSBox, like colon, ultimately could then also be under Shift + AltGr in addition to having their default AltGr + placements. The ample rest of the AltGr + Shift slots if unreserved can be what we would want them to be then.

So in my layout...

AltGr + , is ;

AND

AltGr + . is :

AND

AltGr + Shift + , is also : by default.

Fixed typo.

 

[rygD]

Ok, it seems I should have finished reading recent posts.

 

Black Key edges -will- get their black paint scratched on the frame over time and have light sneak through.

Not if painted on the underside or double shot caps, which should be done either way to prevent the markings from wearing off. My keys will be trashed pretty quickly, and if it is just painted on top I will have areas of paint missing like I do on other thumb keyboards that are painted due to stabbing the keys with my thumbnails sometimes.
 

Symbols could be printed in 'translucent' colors instead of using only black (inked) and white (non-inked).

Didn't ED already say we could get multiple colors?
 

Secondary/tertiary symbols will appear clearer even when using smaller fonts.

Would they? I am not trying to debate it, I just don't recall seeing other things like this, and I figured it would be harder to see something small and opaque in front of a light than the other way around (like trying to see something between the observer and a star vs seeing a little light leaking through a wall in a dark room).
 

Black/color text in small fonts on a white background is easier to read than white/color text in small fonts on a black background.

Can you give me a source for this? I don't think this is the case with backlit displays like it is with things that are viewed with reflected light. I personally find it easier to look at something mostly dark or black with a little light coming through than staring into a light.

It would be probably be easier to see without the keyboard lit in dim light, which would save battery life, kinda like what _wb_ originally said. I really like the option of adding your own labels. A way to make this look a little better than writing it on is using a clear label from a label maker (if the characters can be made small enough).

Comradekingu and Grench and probably others have proposed a similar thing in the past. Use an inverted color scheme where most of the button is transparent and only the label gets ink.

AAAHHHHH, MY EYES!!! SO BRIGHT!  I  know it won't really blind my very light sensitive eyes.  I am not totally against it.  I do find it undesirable if the cap can be colored with only the characters translucent.  The keyboard LEDs probably won't be brighter than the display, but it has happened before on other devices, and it is irritating.

Easy albeit insensitive solution to keyboard back-light sensitivity.

Bight, normal, dim, dimmer, dimmest, off.

That is all fine and dandy if you always have the keyboard LEDs off or on at the same setting, and the display set appropriately as well.  If you have mismatched settings the situation I described may happen.  I tend to have both my keyboard and display on other devices as dim as possible while still being useful to conserve battery life.  I usually change settings so that when it is plugged in everything gets brighter so it is easier to see in a brightly lit room.  If you have the keyboard lighting set to shut off after a set time and lowered screen brightness via touchscreen while plugged in you may forget that the backlight is bright until you get blasted by it.

 

[Grench]

If you're viewing this forum in it's default setting then you're looking at black text on an LED back lit white background.  Same for the colors.

I had given up on the white keys with black/colored letters idea since there was a very vocal backlash around the idea back when it was discussed.  I'm not opposed to revisiting the idea, but I don't see it as very likely.

 

[WizardStan]

So in my layout...

AltGr + , is ;

AND

AltGr + . is :

AND

AltGr + Shift + , is also : by default.

Ooo, I like that idea. Would both ":" be labeled? I would like it if they were, against the objections of others.I can't seem to find this particular proposal of yours though. Was it a few pages back?

 

[rygD]

If you're viewing this forum in it's default setting then you're looking at black text on an LED back lit white background.  Same for the colors.

That is true, and is part of why I sometimes lower the brightness even when plugged in.  I have modified browser colors on a couple of my devices, but that becomes a headache pretty quickly.

I had given up on the white keys with black/colored letters idea since there was a very vocal backlash around the idea back when it was discussed.  I'm not opposed to revisiting the idea, but I don't see it as very likely.

I must have missed this discussion.  I see a lot of the benefits, especially if it gives us a good reason to have a less marked up keyboard and makes customization easier.  I figured I would be in the minority for black key caps.  I  will let it go if people are generally opposed to it, however I wouldn't mind a link to the thread where this was discussed if someone comes across it at some point.

 

[codifies]

So in my layout...AltGr + , is ;ANDAltGr + . is :ANDAltGr + Shift + , is also : by default.

Ooo, I like that idea. Would both ":" be labeled? I would like it if they were, against the objections of others.I can't seem to find this particular proposal of yours though. Was it a few pages back?

Colons are important even Java uses them now!

But I'm still concerned that we don't know if the keyboard is capable of certain 3 key combos, bare in mind matrices can be odd being able to do certain multi key combos but not others...

 

[Saber]

So in my layout...


AltGr + , is ;


AND


AltGr + . is :


AND


AltGr + Shift + , is also : by default.

Ooo, I like that idea. Would both ":" be labeled? I would like it if they were, against the objections of others.
I can't seem to find this particular proposal of yours though. Was it a few pages back?

The AltGr + Shift values wouldn't get a print. Space on the key's caps is just too limited for them to fit. 

I didn't extensively detail the AltGr + Shift values in my layouts besides the diacritics, but I did purposely reserve a few empty slots for the more fickle DOSBox ones like colon and underscore.

 

[WizardStan]

Space on the key's caps is just too limited for them to fit.

I disagree and think it would be worthwhile having such standard characters printed. Not necessarily filling the entire keyboard, but if a character can be produced off two keys they should be labeled as such to avoid confusion. I'm counting up to 10 keys which could benefit from such a combo which shouldn't cause it to appear cluttered.If 3 characters can fit on a key then 4 can for sure as well. It may not look *as* nice, but they would still fit.

 

[Saber]

Space on the key's caps is just too limited for them to fit.

I disagree and think it would be worthwhile having such standard characters printed. Not necessarily filling the entire keyboard, but if a character can be produced off two keys they should be labeled as such to avoid confusion. I'm counting up to 10 keys which could benefit from such a combo which shouldn't cause it to appear cluttered.
If 3 characters can fit on a key then 4 can for sure as well. It may not look *as* nice, but they would still fit.

Fortunately for the sake of rationality, ED prefers keys that are labeled nice and relatively squint-free and less busied, leaving the fourth level modified characters to user memorization, should they ever need them.