You can program them to emulate pretty much what you want. The Kinesis will let you use such pedals as a part of its' layout as I understand it, while non-Kinesis users will use pedals as a separate USB keyboard and/or mouse device (with a separate driver).
]]>http://www.kinesis-ergo.com/fs-savant-elite.htm
http://www.pedalpeddler.com/Index.aspx?p=3
http://www.pedalpax.com/SA1_Foot_Pedal.htm
http://www.specialneedscomputers.ca/kb-footpedal.htm
http://www.bilbo.com/
These devices are recognized by the OS as regular USB keyboards (so they should work for me on NetBSD). However you need a special (Windows-only) program to define the pedal actions, but that's just once.
I would be interested in mapping Ctrl and Shift to a pedal, because I very regularly use such shortcuts and they can get painful after a while.
The problem with Mac is apparantly that one keyboard's modifier keys (Shift, Ctrl, Alt, Option) can't modify another keyboard's input. Other OS'es don't have this limitation.
]]>Not a lot easier, but I do not want Alt-Gr since I need all the Alt and Ctrl I have, with my IME and Code Whatever keyed to different sides. I actually used to produce my own symbols layout where I replaced most of the symbols but I realised, after a few months, that it is not easier then doing min. position change and using your left Shift.
If there are some way I can help with < and > I would like to, too. Maybe I should hunt for a pedal after all...
]]>I still think that your careful optimisation may be quite unwarranted because every four lines of code isn't enough to make any kind of difference in the areas that optimisation is concerned with: Speed and comfort. So I'll reiterate my argument that for these rare(-ish) characters it's not about ergonomy but about intuitive and consistent placement.
I appreciate your input. However, I think you underestimate how often these characters are used. To exemplify: According to my data, several characters that you dub as rare (such as hyphen, *, curly braces and more) are actually more frequent than many English characters (such as w and j) and on par with many others. I feel that if you tried it I might be able to sway you to my way of thinking.
That much being said, I suppose you still want to avoid same-finger digraphs. This would affect for instance several combinations like += -= >= in C languages. Seems to me the '=' should be for instance on the middle right-hand finger, and the others off that finger.
My optimiser respects this as well as several other parameters. You will for instance see that most characters likely to be preceded or followed by a carriage return are on the left hand side.
Again, thanks for your input.
]]>I still think that your careful optimisation may be quite unwarranted because every four lines of code isn't enough to make any kind of difference in the areas that optimisation is concerned with: Speed and comfort. So I'll reiterate my argument that for these rare(-ish) characters it's not about ergonomy but about intuitive and consistent placement. The best optimiser here will be your sense of symmetry and mnemonics. I'd think that given your results, anything past the slash, parentheses and semicolon should be placed not according to where it's easy to reach but where it's easy to remember to reach for it!
That much being said, I suppose you still want to avoid same-finger digraphs. This would affect for instance several combinations like += -= >= in C languages. Seems to me the '=' should be for instance on the middle right-hand finger, and the others off that finger.
You'll notice that my musings have touched upon this topic: https://forum.colemak.com/viewtopic.php?id=364 :)
]]>Hmmm. From your data, it seems that only the slash, parentheses and ;=:_ or so really deserve special attention as the rest must be extremely rare in the whole picture. I don't think that frequencies in that extremely low range you're talking about here have any real impact on speed or general comfort whatsoever, so you should probably focus on ease of learning and remembering when choosing positions.
They are not that rare. Given that there is almost a semicolon per line, the others are probably in the frequency range of one every four lines (if you squint and do a lot of hand waving). Combined, there will be a couple of them per line. I can't hit shift-number combinations without looking down, so if you neglect them that's almost two times looking at the keyboard per line of code. Personally, I don't like that.
I optimised the layout quite carefully. I found that small changes often interacted in unexpected ways. Hence, I don't recommend changing things willy-nilly without running it through an optimiser or, even better, trying it out empirically for yourself. Having said that, I do recommend everyone to modify it to their heart's content since my way will probably not be best for you.
]]>On my Norwegian layout, I reach all those with a simple Shift-press and the underscore already has a reachable AltGr mapping. The {} and <> are more annoying to reach on my layout, and the /|\ chars are spread out making them a bit confusing.
It's nice if you find this useful, but I'm uncertain about the general utility of it. The most appealing thing about it from my point of view, is the intuitive ordering of the various brackets. Since I already have easy access to ;: at the lower right (shift-period and shift-comma), I might want something like:
! " # $ & . . [ ] .
` { } * - . . ( ) .
| \ / = + . . < > _
A few chars should be easy to remember there: Note how the /*-+ form the familiar NumPad sequence (and = nearby), and the !#$& chars are placed right beneath where I'd normally find them with Shift (if not stretching to the upper row really is important enough to have them here).
I can't think of anything I'd really want to fill in the dots with; the 3x2 vacant block could have numbers I suppose - although it'd be even nicer if the numbers 123 and 456 could be placed NumPad-style under 789. In that case, I'd also place /*-+= to the right of those keys as they are on the NumPad. But then the neat bracket system is broken! Hmmm...
! [ ] $ & 4 5 6 -
` ( ) # \ / 1 2 3 +
| { } < > 0 = _
Just toying around with thoughts.
]]>\ { } & | * [ ]
# : ; / 0 1 = ( ) _
! - + 2 3 < > 4
I suppose your line endings is the reason you mapped the semicolon towards the center with respect to the colon? However, I'm unsure whether it's a good idea to reverse the sequence from the comma-dot on the normal board. I think that I'd just map the colon and semicolon to where you put the <> for reasons of mnemonics and simplicity, even if that means having to reach a little more away from the home row.
I put them there since they are frequently used.
The numbers are another matter. Do you need AltGr mappings for them, really? Isn't AltGr plus a key just as much hassle as reaching to the top row for a number - even with a pedal?
I personally do not think so. I use them a lot, especially 0, 1 and 3.
And as far as I can see, you're missing the programming-important caret (^) and grave (`) symbols. You may be too locked up in your two languages to see what other languages need, if you're trying to make something useful for other people too. I imagine it'd be useful to don the shoes of someone using, say, Perl, AutoHotKey and Visual Basic.
True. One of the free slots could be used for those.
Afterthought: How about you tell us what you found from your corpus? I mean, what were the different symbol frequencies?
Here's a printout. Excuse the lack of formatting. Normalised to the most common character.
[('/', 1.0), (')', 0.23), ('(', 0.23), (';', 0.18), ('=', 0.13), (':', 0.13), ('_', 0.11), ('-', 0.09), ('*', 0.09), ('{', 0.08), ('}', 0.08), ('1', 0.08), ('0', 0.08), ('>', 0.07), ('[', 0.06), (']', 0.06), ('#', 0.06), ('&', 0.05), ('2', 0.05), ('<', 0.05), ('"', 0.04), ('3', 0.04), ('!', 0.04), ('+', 0.03), ('4', 0.01), ('|', 0.0)]
]]>\ { } & | * [ ]
# : ; / 0 1 = ( ) _
! - + 2 3 < > 4
Is this what you mean? You didn't specify which keys you meant are the 'future expansion' ones?
If I got it right: I like the way the bracket stuff all fell in line - including the '+-' (and I hope, '<>' and ';:' as well - hence my interpretation of your left-out keys).
I suppose your line endings is the reason you mapped the semicolon towards the center with respect to the colon? However, I'm unsure whether it's a good idea to reverse the sequence from the comma-dot on the normal board. I think that I'd just map the colon and semicolon to where you put the <> for reasons of mnemonics and simplicity, even if that means having to reach a little more away from the home row.
The numbers are another matter. Do you need AltGr mappings for them, really? Isn't AltGr plus a key just as much hassle as reaching to the top row for a number - even with a pedal?
You could probably make the positions of the 'math' symbols such as '!' more intuitive, for instance placing the '!' on the Q key under the number 1 key where the '!' normally resides. (Then again, that's fairly easy to reach up there as well - certainly no worse than reaching the '$' sign which is also important for programming.)
And as far as I can see, you're missing the programming-important caret (^) and grave (`) symbols. You may be too locked up in your two languages to see what other languages need, if you're trying to make something useful for other people too. I imagine it'd be useful to don the shoes of someone using, say, Perl, AutoHotKey and Visual Basic.
Afterthought: How about you tell us what you found from your corpus? I mean, what were the different symbol frequencies?
]]>