To the people who care about sound, audiophiles or objectivists or whatnot, two things matter.
How good is the sound coming out of the device, perceived or not,
and what they have in common:
how managable are the media-controls.
In the price-range of the pyra, if the sound is good enough, you will still sell buckets to either, but it can be _the_ device for this whole market. Its not like these people want to carry around specialized "mp3-players" Or bear the burden of dedicated DAC / amplifier to go with their cellphone. One of the last strongholds of dedicated machinery, but for no good reason. Compare it to how the openpandora at first was a dedicated gaming-machine, but got more laptop as time went by.
I'd refine that definition a bit.
The first point, audio quality, is surely a common concern among that audience.
The second one, media controls, on the other hand only concerns a subset of them that use pyra as a portable audio player. For others the media controls may well be on the keyboard or elsewhere.
Lumping these concerns, and the segments of users along with them, together only serves to muddle the issue and make the media controls appear more of a priority than they might otherwise be perceived as.
EDIT: "portable audio player" meant as a device that fills the use case of displayless mp3 player. Meaning the pyra is closed in this use case. If the pyra is open as in "portable media player" use case, other buttons and keys could be used instead of shoulder buttons.
Why not? You aren't seriously suggesting that the shoulder buttons be used 100% exclusively as media buttons, are you? I'm assuming I'm misunderstanding something because that would be terrible. I know I'm not alone in using the shoulder buttons on the Pandora almost exclusive for shifting.
The issue is selling additional units to people who wouldnt buy the pandora elsewise. You need to do well in the aspect of audio-centric things to capture audio-centric people.
I am suggesting that we have a button called F- which does, in conjunction with the number row, F-keys. In conjunction with shoulders, mediakeys. This means no conflict.
Numbers = numbers
Fing+numbers= F-keys
Shoulders = ctrl alt altGr and shift
Fing+shoulders = mediakeys
TL;DR to have less conflicts you add an additional modifier to do the things there arent buttons for. The alternative is adding those things to less modifiers, which means conflicts because everything is encumbered somehow.
When the lid is closed, you could have the shoulders be mediakeys only, in both cases, but it makes sense to have it be the mediakeys you already learn to use when the lid is open, and for that, you need it to be an unencumbered modifier.
The issue is selling additional units to people who wouldnt buy the pandora elsewise. You need to do well in the aspect of audio-centric things to capture audio-centric people.
I am suggesting that we have a button called F- which does, in conjunction with the number row, F-keys. In conjunction with shoulders, mediakeys. This means no conflict.
Numbers = numbers
Fing+numbers= F-keys
Shoulders = ctrl alt altGr and shift
Fing+shoulders = mediakeys
TL;DR to have less conflicts you add an additional modifier to do the things there arent buttons for. The alternative is adding those things to less modifiers, which means conflicts because everything is encumbered somehow.
So you are saying to have both the "Fing" key as well as the "AltGr"/"Meta"/"Fn" key? What kind of modifier would it be (probably HWM)? Where would it go? What would be sacrificed?
So you are saying to have both the "Fing" key as well as the "AltGr"/"Meta"/"Fn" key? What kind of modifier would it be (probably HWM)? Where would it go? What would be sacrificed?
Moreover, it couldn't probably be a driver-level thing, since I assume the keyboard and game controls are handled with separate drivers. This means it would need to be either an actual Fn-like hardware modifier, or a software modifier paired with a userspace application like inputty faking an input device. In the former case it needs changes to the hardware. In the latter it doesn't matter since there's a special userspace doodad listening to the exact keypresses anyway. It could be implemented with just a userpsace application.
I think at worst the difference in implementation is a little more power-draw compared to not having mediakeys, when the lid is closed. That functionality would also have to be added for every new OS to be ported, but thats a bonus feature you wont get any other way anyhow.
If you have F-ing along with AltGr, then AltGr is AltGr. No meta/Fn-bullshit. It works if the Fing key is in the column-row. You sacrifice being able to shoulder-press to get f-keys.
No symbols all over the keyboard (since what should be the third level modifier+numbers otherwise, is instead the F-keys)
→ Alternativly, No F-keys across QWERTY-row. (Wasnt as popular, looks messy.)
→→No extra visual clutter of having to print F1-F10 in addition to numbers
Between putting F- at the bottom of the column-row and putting ctrl-alt there,
F-ing at bottom
It is now possible to press F5 F6 and F7 with one hand
Ctrl+alt + 5 6 7 in sequence (the one i went for)
It is now possible to get dead-key aigu, retroflex and grave. This makes it much easier for french people since its the closest one can get to their standard of one press of the number buttons produces dead-keys. It is of course also handy for others.
If nub 1 and 2 along with ↓←→ and <^v> is the /dev/joystick. It is possible to use lidclose as an KeyPress event, where each shoulder just sends a different keycode or change the buttonmapping of the joystick from Ctrl Shift Alt AltGr when you do close the lid.
I still don't get how this is DosBox friendly. It doesn't seem to make any difference vs your other suggestion. The problematic Fn keys are still on Fn keys, just in different places.
DosBox versions are NOT DosBox and/or QEMU compliant/compatible.
For example:
{ symbol must be shift+[
) symbol must be shift+0
+ symbol must be shift+=
~ symbol must be shift+`
To my understanding, for those to work properly, all symbols MUST be paired as they are on the standard US keyboard. Yes, this removes a lot of flexibility in layout design. Yes, this also means we NEED to have 4 symbols on some keys using an Fn type modifier simply to keep the key pairs together.
All standard US symbol keys paired for DosBox and QEMU compatibility? Check.
Dedicated ESC key? Check.
Capable of being used with the shoulder buttons (handheld) and without (desktop & or docking station connected)? Check.
Keyboard modifier keys paired lower left to right shoulder and lower right to left shoulder? Check.
Commonly used Fn+Shift chordable on both sets? Check.
Additional symbols required for German, French and Spanish present? Check.
Uses lid switch to throw shoulder buttons into audio controls mode? Check.
Includes all of the hardware controls for radios, ports and back lighting? Check.
Has Ins and Del in the logical set with Home, End, PgUp and PgDn? Check.
Drawbacks/criticism and answers to critics:
German, French and Spanish symbols are not 'where they're supposed to be' compared to each region's AtlGr keyboard.
The root answer to this is, it is not possible - we do not have enough keys to make a true AltGr international keyboard. The fact that they MUST be in non-traditional Fn handled positions dictates that they be labeled as such.
Oh noes there are symbols I don't recognize from grade school in and it confuses me! Nobody I know is smart enough to figure out that keyboard!
Grow up - there is a big world out there. English is still the primary language on the machine and all of your friendly letters and symbols are easy to find in the same or nearly the same spots as they are on your desktop keyboard. After you get over the, 'One language to rule them all,' thing, then go find smarter friends. International use is part of the spec and I'd say part of the charm of the Pyra. Anyone who can't stand to have a German character on their English as a primary language German built device is simply an ethnocentric pig and -should- be ignored.
The F-keys aren't on the number keys and that messes with my Feng Shui needs!
There are 12 F keys on a standard US keyboard. There are not 12 buttons on the top row of the Pyra keyboard. As such, every layout that puts them there compromises by shoving F11 and F12 somewhere else. By moving them one row down to where there ARE 12 buttons it allows them to be a contiguous set AND frees up the Fn+numberkey combinations to handle additional symbols. Many of these are deliberate mnemonic place holders. The audience for the Pyra may be unlikely to use those symbols in currency transactions, BUT it allows a visual mnemonic for mapping additional symbols that we cannot predict to a visually identifiable symbol.
We can't have more than 3 symbols on a key! It's too cluttered and too confusing!
Not really. That was an arbitrary statement a long time ago and would dictate that DosBox would NEVER be able to be properly mapped to the device AND that additional language support would be an even worse compromise. The individuals making this statement don't seem to realize that every key has 4 (or more for F1-F12) mappings - even on the layouts where it is not expressed. Consider a key with A and Ä mapped to it. Each of those is actually a lie. Unshifted it is actually a and ä. However, that key has 4 symbols associated with it even if there are only two symbols printed on the key.
Sorry to be terse and a bit of an ass, but we're spinning our wheels making non-substantive changes.
Now that we know it is all -possible-, my inclination is to flunk any layout that dos not:
1. Work with DosBox and QEMU on all expected symbol pairs.
2. Include the necessary symbols for German and French. If possible, add Spanish.
3. Work for all needed symbols when used both in the hands AND in a docking station where the shoulder buttons will be inaccessible.
The issue is selling additional units to people who wouldnt buy the pandora elsewise. You need to do well in the aspect of audio-centric things to capture audio-centric people.
I am suggesting that we have a button called F- which does, in conjunction with the number row, F-keys. In conjunction with shoulders, mediakeys. This means no conflict.
Numbers = numbers
Fing+numbers= F-keys
Shoulders = ctrl alt altGr and shift
Fing+shoulders = mediakeys
TL;DR to have less conflicts you add an additional modifier to do the things there arent buttons for. The alternative is adding those things to less modifiers, which means conflicts because everything is encumbered somehow.
When the lid is closed, you could have the shoulders be mediakeys only, in both cases, but it makes sense to have it be the mediakeys you already learn to use when the lid is open, and for that, you need it to be an unencumbered modifier.
Maybe I'm missing something, but programs like VLC allow you to set whatever keys you want to a given media function, so what exactly is the problem here? A user can just bind the keys/buttons they want in-program. It seems like you're looking at the Pyra the same way as something like an iPhone and such, where there is one primary/built-in media player with limited customizing ability. The Pyra is slated to have a full OS, which means you're free to use which ever software best suits your needs, that allows you to customize things as one needs (and if that is not enough, there is also the option of compiling VLC or what have you yourself after making the mods one wants.)
I still don't get how this is DosBox friendly. It doesn't seem to make any difference vs your other suggestion. The problematic Fn keys are still on Fn keys, just in different places.
I thought the problem with DOSBox was that Semicolon and Colon are Fn/AltGr values on Comma and Period? Since the program expects Colon to be a shifted value over Semicolon, the issue I believed is how the program incorrectly interprets the Fn output, where they were put on the Pandora. I had thought Comma and Period’s location was the source of this complication.
I have now removed the DOSBox friendly version, but I would appreciate it next time if you, or others, don’t wait to bring any issues you discover to the forefront right away. It delays the process when vital information is held on to. Of course, like in Grench's layout, we can Shift + AltGr to derive the Colon symbol in DOSBox.
While I have you here, is there anything positive you have to say(about v2)? Barring a complete redesign or another's layout entirely, what would you and others change and why(and realistically how)?
Ok, concerning the Alt-keys, I recall you mention that right-Alt and AltGr are really the same key in International keyboard layouts/mappings. In many places this seems to be the case, especially in Windows, but under Linux, AltGr appears to emit a keycode of 225 why the Alt keys give 17. What I'm unsure of is if this is just a mapping in most Linux systems or if 225 is the proper keycode for AltGr. On some platforms, such as Windows, AltGr actually just maps to Ctrl+Alt, which makes me wonder what actually is the correct definition of AltGr.
Wb: The problem with putting meta on a shoulder is that you cant then use the shoulders as mediabuttons. Meta is the hack, and thus, it should be free to use in conjunction with shoulders.
Huh? Why not? I would propose to let shoulder taps correspond to mouse clicks when the lid is open, and media buttons when it is closed. I have detailed these mechanisms elsewhere. My proposal (http://www.keyboard-layout-editor.com/#/layouts/f9f3508ae2ea1ed6de939d0100173675) is to let the Pyra button (the one below SELECT) be LeftSuper, and the lid sensor would be RightSuper. So the lid acts like a key, the lid being closed is RightSuper being held down, the lid being open is RightSuper being released. We could perfectly well make sure that Super+[whatever keys the shoulder buttons correspond to] map to media buttons, or to anything else the user likes.
It makes perfect sense to put the most important modifiers (Shift, Ctrl, Alt and Meta) on the shoulder buttons. This does not mean we can't also use the shoulder buttons as media buttons and mouse clicks. We can have our pie and eat it twice, in this case.
Ok, concerning the Alt-keys, I recall you mention that right-Alt and AltGr are really the same key in International keyboard layouts/mappings. In many places this seems to be the case, especially in Windows, but under Linux, AltGr appears to emit a keycode of 225 why the Alt keys give 17. What I'm unsure of is if this is just a mapping in most Linux systems or if 225 is the proper keycode for AltGr. On some platforms, such as Windows, AltGr actually just maps to Ctrl+Alt, which makes me wonder what actually is the correct definition of AltGr.
Whatever AltGr and Right Alt share between them on other keyboards, on the Pyra, they will not share the same keycode. We couldn't have a regular vanilla Right Alt(without Mode_Switch?) on the R2 shoulder button and an AltGr key dissimilar to it on L2 then.
Seems like ED wants two shifts on the keyboard, as well as the German keys there. Any comments on the relative value of these layouts? Dedicated Esc and Super, plus all the keys that Saber has.
F11 and F12 hit P and right keyboard shift, so that most umlauts can go on the corresponding vowel:
in both layouts, I still have an open position for AltGr+Y, so if anyone has any creative ideas, I'm happy to put them in. Somebody at one point wanted the Yen symbol, but I'm not sure how often that will be used otherwise .
- what does "Diacritic DeadKey" do? Is it some sort of modifier key? Or Compose?
- dedicated Fn keys for äüöß for German, OK. Dedicated ç and ñ for Spanish/Portuguese/French, OK. But why Æ and Œ? Feels like a rather random selection of special symbols.
- comma and period as non-primary keys is a step backwards compared to Pandora
- semi-nonsensical symbols like § ¥ ł ৳ ₪, I don't really see the point. It just adds clutter, and I don't think it really helps as a mnemonic for remappers.
- labeled keys for USB/3G and WiFi/BT seem like a bad idea, since there is probably more hardware stuff we want to have toggles for, while the toggles we think about now might turn out to be irrelevant (e.g. USB may not use any power when not in use, so no reason to toggle it). I prefer my solution of having one 'hardware settings' button that shows an overlay menu (implemented in (low-level) software).
- in my experience, Ctrl and Alt lock is something you never need, and which is annoying if you accidentally enter it.
- What is the normal function of START/SELECT/PAUSE (without Fn)? Which button would you use to "show the Start menu" (the 'Pandora' button)?
Saber:
- How do you solve the three shift problem? Do you make the two keyboard shifts both look like a LeftShift, so they cannot be distinguished?
- Same remark as above about the 'hardware toggles'.
- Is AltGr+N a dead acute accent? A bit weird to have dead acute labeled but none of the other diacritics.
- Why a dedicated AltGr key for § and µ? Don't seem to be important symbols to me.
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.
