My proposed synthesis layout (
http://www.keyboard-layout-editor.com/#/layouts/4f6ce9cc204bf2037187d57c9485f740) does not have labels for Greek and Math on the keymat. The text on the right, which are suggestions for default software mappings, are not supposed to be printed on the keymat. The text
"Pyra keyboard layout proposal
compromise proposal
18 July 2015"
is also not supposed tot be printed on the keymat.
What you have printed on the right are basically project design requirements - the instructions and clarifications of what needs to be done to make it work. You included that in there - so at that point it IS a design requirement. The Greek/Math thing is an unnecessary design element that should be shed from the initial release. It complicates and adds a LOT of extra fat to the keyboard layout build process. Someone would have to build the logic to 'lock' Greek/Math forward AND build those translation tables between the key codes and the resulting character codes. If you want to build that 'feature' as a secondary or alternative keyboard driver or PND equivalent after release - cool. It does not need to be there - or referenced in the design document now.
You seem to be confused about how keyboards work. Do you really think that something like Greek/Math (or the dead diacritics for that matter) would be handled directly by the hardware or hardcoded in the low-level keyboard driver? That would be insane. Features like this should be handled using xkb configuration files and custom Compose sequences (Compose sequences do not have to start with a press of the Compose key, dead diacritics can also be handled as Compose sequences).
Here is an example of such configuration files for "dead Greek" and "dead currency symbol":
http://download.tuxfamily.org/dvorak/xkb/fr-dvorak-bepo-xkb-1.0rc2.tgz
The comments I put on the right hand side of all my proposals, including the synthesis proposal in the first post of this thread, are not "design requirements". They're just suggestions for the default software configuration. I write those suggestions to ensure that a sensible default is possible, combining as many features as I can think of without internal inconsistencies. But by no means does this actually have to be the default configuration.
We can always decide that e.g. dead caron, dead stroke, dead grave, dead Greek or dead Math should
not be in the default configuration, for whatever reason (e.g. to avoid confusion when a user presses those unlabeled Shift+Fn keys, which is a valid concern). There is no obligation whatsoever to implement that functionality,
because those things are not labeled on the keymat. Still, it's good to know that the option is there to do it. If someone wants MATH at Shift+Fn+M, then it can be done because that combination is not already in use. In the original layout 7, there was ç at Fn+M, which means Shift+Fn+M should produce Ç so there is no room there for MATH (or µ, or whatever you might want to put on Shift+Fn+M, unless you break the expectations of the label and drop the capital version of ç).
Anyway, we are deciding now what labels to put on the physical keymat. There are lots of choices to be made regarding the default software configuration: sticky Shift or non-sticky Shift, grave/tilde dead by default or not, Shift+Shift for Shift Lock and Meta+Meta for Meta Lock, media keys at Super+shoulders or not, dead Greek or not, and so on, and so on. The only constraint we create, the only commitment we have to make right now, is what is actually going to be printed on the keymat. The default software configuration should respect what is shown on the actual hardware. The "Greek/Math thing", as well as many other things suggested in those notes on the right, is not one of those commitments. Unlike how it was in layout 2 from the poll.
In any case, whatever the default configuration will be, I would like to make a modular set of configuration files with a nice simple GUI dialog box to let you customize things a bit (for deep customization you'll have to edit the actual config files yourself).
Again, you're starting at the wrong perspective. You took your #2 layout design and made it more like #7, #1, #10 and #11. Everything that scored at or less than #6 (including #6) should probably be discarded from consideration at this point. Individual features (F11/F12 in attic) may be something to look at IFF it can be done without wrecking the features, themes and aesthetics that are present in the Gold (#7), Silver (#1) and Bronze (#10) layouts - with preference to that order.
I still want to know what ED's plans are - he has so far chosen not to share them.
No, I started with the template I have been using lately (which closer resembles the actual shape of the keys), and put layout 7 on it. Then I made some changes to make it more like layout 1 in its positioning of the non-ASCII letters, I reordered the bottom two rows for efficiency (which was the main advantage of layout 10: important Fn symbols easy to reach) while maintaining the Shift-pair convention of layout 7, and I put F11/F12 up top. That's basically it.
It is not at all like layout 2, which has Delete/Backspace on the action buttons, a dedicated -_ key, Esc at Fn+Q, Caps Lock at Fn+Tab, F11/F12 at Fn+O/P, a dedicated Pause key and a hardware key, Shift and Fn on the left, Insert on Fn+Space, and labeled GREEK and MATH keys at Fn+G and Fn+M. The only thing I took from that was the
option to have
unlabeled GREEK and MATH keys at
Shift+Fn+G/M.
