<?xml version="1.0"?>
<root>
<!-- This file is a Keyremap4MacBook definition file that allows you to use the "SpaceFN"
keyboard layout on your Mac.
The main point of the SpaceFN layout is to turn your spacebar into a single big "Fn" key
that will give you access to all the navigation and function keys without moving your hand
from the home row.
SpaceFN can work on any keyboard, but is especially well suited for "60%" ones because
it allows access to all the navigation and function keys from the alphabetical cluster.
It doesn't require a dedicated Fn key and doesn't change the primary function of any key.
HOW TO USE:
- You must have KeyRemap4MacBook installed on your Mac, or you must install it first.
KeyRemap4MacBook works on ALL Macs, is free, and is available here:
https://pqrs.org/macosx/keyremap4macbook/
- NOTE: "private.xml" is the file where one can create shortcuts and definitions that
KeyRemap4MacBook will use.
It is located in /Users/you/Library/Application Support/KeyRemap4MacBook
To access it with the Finder:
- Open a Finder window
- Click on the "Go" menu
- Press and hold the Option key (Alt if you have PC keyboard)
- Click on Library
- Release the Option key
- Open "Application Support"
- Open "KeyRemap4MacBook"
Now you are in the folder where the "private.xml" file should be. You may not have
one at this time, so the folder may be empty.
- If you already have a "private.xml" file:
- Save this text as SpaceFN.xml in the same directory as your "private.xml" file.
- Edit your "private.xml" file and add this line after the first "<root>" line:
<include path="SpaceFN.xml" />
NOTE: to edit the file you may need to right-click it, go to "Open with" and finally
click on "TextEdit.app".
So your private.xml file may look like this:
<?xml version="1.0"?>
<root>
<include path="SpaceFN.xml" />
</root>
- Save the file.
- Open KeyRemap4MacBook (it has a "KEY" icon), then click on "Reload XML".
- Check this box: "SpaceFN layout - Basic stuff"
- Consider checking some of the other "SpaceFN layout" boxes depending on your needs.
Changes take place immediately.
- If you don't have a "private.xml" file already:
- Save this text as "private.xml" in the folder where private.xml is supposed to be.
- Open KeyRemap4MacBook (it has a "KEY" icon), then click on "Reload XML".
- Check this box: "SpaceFN layout - Basic stuff"
- Consider checking some of the other "SpaceFN layout" boxes depending on your needs.
Changes take place immediately.
-->
<item>
<name>SpaceFN layout - Cmd+Left/Right skips word by word</name>
<appendix>If you don't activate this, Cmd+Left/Right goes to beginning or end of line.</appendix>
<identifier>remap.KB607_CmdWords_ct</identifier>
<autogen>--KeyToKey-- KeyCode::J, ModifierFlag::EXTRA4 | VK_COMMAND,
KeyCode::CURSOR_LEFT, ModifierFlag::OPTION_L</autogen>
<autogen>--KeyToKey-- KeyCode::L, ModifierFlag::EXTRA4 | VK_COMMAND,
KeyCode::CURSOR_RIGHT, ModifierFlag::OPTION_L</autogen>
</item>
<item>
<name>SpaceFN layout - Cmd+Up/Down does PgUp/PgDn</name>
<appendix>If you don't activate this, Cmd+Up/Down goes to top or bottom of document.</appendix>
<identifier>remap.KB607_CmdUpDown_ct</identifier>
<autogen>--KeyToKey-- KeyCode::I, ModifierFlag::EXTRA4 | VK_COMMAND,
KeyCode::PAGEUP</autogen>
<autogen>--KeyToKey-- KeyCode::K, ModifierFlag::EXTRA4 | VK_COMMAND,
KeyCode::PAGEDOWN</autogen>
</item>
<item>
<name>SpaceFN layout - Basic stuff</name>
<appendix></appendix>
<appendix>You must check at least this box to activate the SpaceFN features.</appendix>
<appendix></appendix>
<appendix>ARROWS: Space+IJKL=arrows</appendix>
<appendix>DEL: Space+Backspace=Del</appendix>
<appendix>INS: Space+\=Ins</appendix>
<appendix>BLANK: Space+B=Repeating space</appendix>
<appendix>Fxx: Space+1…=F1..F12</appendix>
<appendix></appendix>
<appendix>IMPORTANT: in the "Key Repeat" tab, you must set:</appendix>
<appendix>- Initial modifier wait: 150ms</appendix>
<appendix>- Timeout: 300ms</appendix>
<appendix>- Delay until repeat: 500ms</appendix>
<identifier>remap.KB607_ct</identifier>
<!-- Space is our new Fn modifier -->
<autogen>--KeyOverlaidModifier-- KeyCode::SPACE,
KeyCode::VK_MODIFIER_EXTRA4, KeyCode::SPACE</autogen>
<!-- Arrow keys: IJKL -->
<autogen>--KeyToKey-- KeyCode::I, ModifierFlag::EXTRA4,
KeyCode::CURSOR_UP</autogen>
<autogen>--KeyToKey-- KeyCode::J, ModifierFlag::EXTRA4,
KeyCode::CURSOR_LEFT</autogen>
<autogen>--KeyToKey-- KeyCode::K, ModifierFlag::EXTRA4,
KeyCode::CURSOR_DOWN</autogen>
<autogen>--KeyToKey-- KeyCode::L, ModifierFlag::EXTRA4,
KeyCode::CURSOR_RIGHT</autogen>
<!-- DEL on space+Enter -->
<autogen>--KeyToKey-- KeyCode::DELETE, ModifierFlag::EXTRA4,
KeyCode::FORWARD_DELETE</autogen>
<!-- INS on space+Tab -->
<autogen>--KeyToKey-- KeyCode::BACKSLASH, ModifierFlag::EXTRA4,
KeyCode::PC_INSERT</autogen>
<!-- space+B is an autorepeat space -->
<autogen>--KeyToKey-- KeyCode::B, ModifierFlag::EXTRA4,
KeyCode::SPACE</autogen>
<!-- Function keys -->
<autogen>--KeyToKey-- KeyCode::KEY_1, ModifierFlag::EXTRA4,
KeyCode::F1</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_2, ModifierFlag::EXTRA4,
KeyCode::F2</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_3, ModifierFlag::EXTRA4,
KeyCode::F3</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_4, ModifierFlag::EXTRA4,
KeyCode::F4</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_5, ModifierFlag::EXTRA4,
KeyCode::F5</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_6, ModifierFlag::EXTRA4,
KeyCode::F6</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_7, ModifierFlag::EXTRA4,
KeyCode::F7</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_8, ModifierFlag::EXTRA4,
KeyCode::F8</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_9, ModifierFlag::EXTRA4,
KeyCode::F9</autogen>
<autogen>--KeyToKey-- KeyCode::KEY_0, ModifierFlag::EXTRA4,
KeyCode::F10</autogen>
<autogen>--KeyToKey-- KeyCode::MINUS, ModifierFlag::EXTRA4,
KeyCode::F11</autogen>
<autogen>--KeyToKey-- KeyCode::EQUAL, ModifierFlag::EXTRA4,
KeyCode::F12</autogen>
</item>
<item>
<name>SpaceFN layout - ESC on backquote</name>
<appendix>Check this box to have the backquote key do Escape.</appendix>
<appendix>You don't need this if you have both the ESC and backquote keys on your keyboard.</appendix>
<appendix>F.e. you don't need to check it on an HHKB, but you need it (or the next checkbox) on a Poker.</appendix>
<appendix>You get backquote ( ` ) with space+M and tilde ( ~ ) with space+comma.</appendix>
<appendix>Note to non-QWERTY users: these are the keys below and to the right of J and K.</appendix>
<identifier>remap.KB607CT_esc_ct</identifier>
<autogen>--KeyToKey-- KeyCode::BACKQUOTE,
KeyCode::ESCAPE</autogen>
<autogen>--KeyToKey-- KeyCode::M, ModifierFlag::EXTRA4,
KeyCode::BACKQUOTE</autogen>
<autogen>--KeyToKey-- KeyCode::COMMA, ModifierFlag::EXTRA4,
KeyCode::BACKQUOTE, ModifierFlag::SHIFT_L</autogen>
</item>
<item>
<name>SpaceFN layout - ESC on space+E</name>
<appendix>Check this box to have space+E do Escape.</appendix>
<appendix>You don't need this if you have both the ESC and backquote keys on your keyboard.</appendix>
<appendix>For example you don't need to check it on an HHKB, but you may want to activate it on a Poker.</appendix>
<identifier>remap.KB607CT_esc_on_E_ct</identifier>
<autogen>--KeyToKey-- KeyCode::E, ModifierFlag::EXTRA4,
KeyCode::ESCAPE</autogen>
</item>
<item>
<name>SpaceFN layout - PgUp, PgDn, Home, End (MAC MODE)</name>
<appendix>HOME/END: Space+U=Home Space+O=End (begin and end of DOCUMENT)</appendix>
<appendix>PAGE UP/DOWN: Space+H=PgUp Space+N=PgDn (cursor does NOT move)</appendix>
<identifier>remap.KB607_pg_macmode_ct</identifier>
<autogen>--KeyToKey-- KeyCode::U, ModifierFlag::EXTRA4,
KeyCode::HOME</autogen>
<autogen>--KeyToKey-- KeyCode::O, ModifierFlag::EXTRA4,
KeyCode::END</autogen>
<autogen>--KeyToKey-- KeyCode::H, ModifierFlag::EXTRA4,
KeyCode::PAGEUP</autogen>
<autogen>--KeyToKey-- KeyCode::N, ModifierFlag::EXTRA4,
KeyCode::PAGEDOWN</autogen>
</item>
<item>
<name>SpaceFN layout - PgUp, PgDn, Home, End (PC MODE)</name>
<appendix>HOME/END: Space+U=Home Space+O=End (begin and end of LINE)</appendix>
<appendix>PAGE UP/DOWN: Space+H=PgUp Space+N=PgDn (cursor MOVES to the new page)</appendix>
<appendix>Goodies:</appendix>
<appendix>- Cmd+up/down does Mac mode PgUp/PgDn (cursor does not move)</appendix>
<appendix>- Cmd+left/right does Home/End</appendix>
<appendix>- Cmd+Home/End goes to the top/bottom of document</appendix>
<identifier>remap.KB607_pg_pcmode_ct</identifier>
<autogen>--KeyToKey-- KeyCode::U, ModifierFlag::EXTRA4 | VK_COMMAND,
KeyCode::CURSOR_UP, VK_COMMAND</autogen>
<autogen>--KeyToKey-- KeyCode::U, ModifierFlag::EXTRA4,
KeyCode::CURSOR_LEFT, VK_COMMAND</autogen>
<autogen>--KeyToKey-- KeyCode::O, ModifierFlag::EXTRA4 | VK_COMMAND,
KeyCode::CURSOR_DOWN, VK_COMMAND</autogen>
<autogen>--KeyToKey-- KeyCode::O, ModifierFlag::EXTRA4,
KeyCode::CURSOR_RIGHT, VK_COMMAND</autogen>
<autogen>--KeyToKey-- KeyCode::H, ModifierFlag::EXTRA4,
KeyCode::PAGEUP, ModifierFlag::OPTION_L</autogen>
<autogen>--KeyToKey-- KeyCode::N, ModifierFlag::EXTRA4,
KeyCode::PAGEDOWN, ModifierFlag::OPTION_L</autogen>
</item>
<item>
<name>SpaceFN layout - Mute, Vol-, Vol+</name>
<appendix>Check this box to have space + "P", "[" and "]" do Mute, Vol- and Vol+.</appendix>
<appendix>Note for non-QWERTY users: it's P and the two keys on the right.</appendix>
<identifier>remap.KB607CT_vol_ct</identifier>
<autogen>--KeyToConsumer-- KeyCode:: P, ModifierFlag::EXTRA4,
ConsumerKeyCode::VOLUME_MUTE</autogen>
<autogen>--KeyToConsumer-- KeyCode::BRACKET_LEFT, ModifierFlag::EXTRA4,
ConsumerKeyCode::VOLUME_DOWN</autogen>
<autogen>--KeyToConsumer-- KeyCode::BRACKET_RIGHT, ModifierFlag::EXTRA4,
ConsumerKeyCode::VOLUME_UP</autogen>
</item>
<item>
<name>SpaceFN layout - PrintScreen, ScrollLock, Pause</name>
<appendix>Check this box to have space + "P", "[" and "]" do PrtScr, ScrLk and Pause.</appendix>
<appendix>Please note that these keys are rarely needed on a Mac.</appendix>
<appendix>Note for non-QWERTY users: it's P and the two keys on the right.</appendix>
<identifier>remap.KB607CT_prtsc_ct</identifier>
<autogen>--KeyToKey-- KeyCode:: P, ModifierFlag::EXTRA4,
KeyCode::PC_PRINTSCREEN</autogen>
<autogen>--KeyToKey-- KeyCode::BRACKET_LEFT, ModifierFlag::EXTRA4,
KeyCode::PC_SCROLLLOCK</autogen>
<autogen>--KeyToKey-- KeyCode::BRACKET_RIGHT, ModifierFlag::EXTRA4,
KeyCode::PC_PAUSE</autogen>
</item>
</root>
you just made a filco minila lol.
but ya, your layout needs to accommodate users who left space. I don't see any reason why that's not standard already.
I like this idea a lot. I have a feeling most people will want to tweak the "fn layer" differently from yours depending on what keys they use most and how they want the arrows to be oriented, etc. But I think it's a great starting point and I like how you've put some thought into the Fn layer. And I think you're right, you could implement this on an ergodox -- you could use the "backspace" key on the left thumb as another fn-layer dual trigger too. I think I'm gonna try it.
Sounds like a great idea. I do use the repeated space functionality enough that I don't think space-b would be a natural replacement. How about double tap the space bar (2 taps in X milliseconds) to trigger repeating?
^WheelDown::return
^WheelUp::return
!q::Send !{F4}
Insert::Backspace
#MaxHotkeysPerInterval 1000
CapsLock::Control
Installation was pretty confusing at first (installing Dual). But it works now. At first glance I thought the arrow keys would've been space+ hjkl, like vim, but this is interesting too. The space coming at the end of the stroke trips me out too. It doesn't feel normal. Lol. But I'm going to try to get used to it.Good work.
I wonder what other things we could include into the function layer that would be useful?
Would it be possible to remap the caps lock button to delete? I think it would be more ergonomic that way.
Another question is, how can I use it with my other autohotkey code?
here it is:Code: [Select]^WheelDown::return
^WheelUp::return
!q::Send !{F4}
Insert::Backspace
#MaxHotkeysPerInterval 1000
CapsLock::Control
Installation was pretty confusing at first (installing Dual).
The space coming at the end of the stroke trips me out too. It doesn't feel normal. Lol. But I'm going to try to get used to it. Good work.
Another question is, how can I use it with my other autohotkey code?
here it is:Code: [Select]^WheelDown::return
^WheelUp::return
!q::Send !{F4}
Insert::Backspace
#MaxHotkeysPerInterval 1000
CapsLock::Control
Sounds like a great idea. I do use the repeated space functionality enough that I don't think space-b would be a natural replacement. How about double tap the space bar (2 taps in X milliseconds) to trigger repeating?
It's supported by TMK, Hasu's firmware. It is not supported by the current software simulations for Windows and Mac.
However it would be great if a consensus could be found on a handful of such layers:
- one for arrows on IJKL
- one for arrows on HJKL
- one for arrows on WASD
Now I would like to build the HJKL layer, so I would like to know the standard way of laying the navigation keys in HJKL:
- order of the arrows
- Home/End
- PgUp/PgDn
- are there more keys that are traditionally used in HJKL?
Actually, double-press-to-repeat actually _is_ possible with my AHK implementation :) It's just disabled by default, since I asked spiceBar about this when implementing it. Add for example `doublePress=200` as a command line parameter to enable it. (In that example, 200 means the maximum number of milliseconds between two presses. Change it if needed.)
Here are my thoughts on the WASD and HJKL modes.
tl;dr:
WASD: Nah.
HJKL: Worth exploring.
WASD might sound good, since a lot of people are used to it from games. But most people are used to the regular arrow keys on the right, too. So IJKL should be equally good. But perhaps for left-handed people? No, I don't think so. I'm right-handed, and I have no problems using WASD (that is, using my left hand) to navigate when gaming. And both my hands are equally good at typing. So I see no benefit in WASD. Instead, it only destroys all the thought you put into SpaceFN about not messing with the left side of the keyboard where loads of useful keyboard shortcuts exist. We can't just move the arrow keys, we'd have to move all the other SpaceFN keys to the left side too, which would basically destroy every common keyboard shortcut.
Okay, how do we create the HJKL mode? H is already taken by Page Up. The easiest solution is of course to put Page Up on the now unused I key. But that breaks the nice "Page Up is above Page Down" thing (H and N). So perhaps comma and N should be swapped as well. That sounds nice to me.
However it would be great if a consensus could be found on a handful of such layers:For IJKL, I am partial to the Numpad layout but with Down on the equivalent to 5 (K).
- one for arrows on IJKL
- one for arrows on HJKL
- one for arrows on WASD
We cannot use 0 and $: They are already assigned to function keys.Let me heretical here for a moment ( ;) ) and suggest A for Home and E for End.
What do VIM users want for Home/End?
However it would be great if a consensus could be found on a handful of such layers:For IJKL, I am partial to the Numpad layout but with Down on the equivalent to 5 (K).
- one for arrows on IJKL
- one for arrows on HJKL
- one for arrows on WASD
For HJKL, I suggest you do like the "vi" editor: left,down,up,right.
I think that those variants would perhaps not be the most efficient, but the ones that the highest number of people are accustomed to.
I have been using a G80-1800 a lot, and so I used Home/End/PageUp/PageDown on the numpad more often than the keys above it, because they were easier to reach.We cannot use 0 and $: They are already assigned to function keys.Let me heretical here for a moment ( ;) ) and suggest A for Home and E for End.
What do VIM users want for Home/End?
Together with Ctrl, those are used for beginning-of-line and end-of-line in Emacs.... but also in the GNU Readline library which is used in loads of other software such as the Bash shell.
I am neither a Emacs or VI user myself, but am used to using Ctrl-A and Ctrl-E under Linux.
I have been googling this for one hour and it looks like these shortcuts are commonly used:
$: End
0: Home
B: PgUp
F: PgDn
We cannot use 0 and $: They are already assigned to function keys.
What do VIM users want for Home/End?
Would U/I for Home/End and N/M for PgUp/PgDn be acceptable?
Can you provide some way to lock the FN layer?
Here is what I tend to do when surfing the internet reading articles or forums.
I use the arrow keys to move up and down the page. This takes one finger on one hand. I don't have to constantly hold a key.
When finished I use alt+left arrow to go back (works in google chrome, not sure about others).
It seems like if I can't lock the FN layer, in those situations when I'm just trying to relax and read something, I'll need to hold the spacebar while arrowing down. Then when I want to go back I'll have to use alt+space+J. If I was trying to do that while keeping my hands on the home row I'd end up using my pinky for the alt which would be very uncomfortable.
A few things I noticed:
- In one of the images in the OP, "Menu" is on slash. Should it be there or not?
- Only the first IJKL layout includes extra backtick and tilde keys.
- Is the second IJKL layout supposed to have two down keys?
- The HJKL layout pust a key on Y—didn't you say some time it was a problem? Something with QWERTZ?
- Is the second IJKL layout supposed to have two down keys?
Yes, the second IJKL layout is supposed to have 2 down keys. I have followed the idea of the Matias Optimizer keyboard.
/*
* SpaceFN
* http://geekhack.org/index.php?topic=51069.0
*/
const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
/* Keymap 0: Default Layer
* ,-----------------------------------------------------------.
* |Esc| 1| 2| 3| 4| 5| 6| 7| 8| 9| 0| -| =|Backsp |
* |-----------------------------------------------------------|
* |Tab | Q| W| E| R| T| Y| U| I| O| P| [| ]| \|
* |-----------------------------------------------------------|
* |Caps | A| S| D| F| G| H| J| K| L| ;| '|Return |
* |-----------------------------------------------------------|
* |Shift | Z| X| C| V| B| N| M| ,| .| /|Shift |
* |-----------------------------------------------------------|
* |Ctrl|Gui |Alt | Space |Alt |Gui |App |Ctrl|
* `-----------------------------------------------------------'
*/
KEYMAP_ANSI(
ESC, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, MINS,EQL, BSPC, \
TAB, Q, W, E, R, T, Y, U, I, O, P, LBRC,RBRC,BSLS, \
CAPS,A, S, D, F, G, H, J, K, L, SCLN,QUOT, ENT, \
LSFT,Z, X, C, V, B, N, M, COMM,DOT, SLSH, RSFT, \
LCTL,LGUI,LALT, FN0, RALT,RGUI,APP, RCTL),
/* Overlay 1: SpaceFN
* ,-----------------------------------------------------------.
* |` | F1| F2| F3| F4| F5| F6| F7| F8| F9|F10|F11|F12|Delete |
* |-----------------------------------------------------------|
* | | | | | | | |Hom|Up |End|Psc|Slk|Pau|Ins |
* |-----------------------------------------------------------|
* | | | | | | |PgU|Lef|Dow|Rig| | | |
* |-----------------------------------------------------------|
* | | | | | |Spc|PgD|` |~ | | | |
* |-----------------------------------------------------------|
* | | | | | | | | |
* `-----------------------------------------------------------'
*/
KEYMAP_ANSI(
GRV, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, DEL, \
TRNS,TRNS,TRNS,ESC, TRNS,TRNS,TRNS,HOME,UP, END, PSCR,SLCK,PAUS,INS, \
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,PGUP,LEFT,DOWN,RGHT,TRNS,TRNS, TRNS, \
TRNS,TRNS,TRNS,TRNS,TRNS,SPC, PGDN,GRV, FN1, TRNS,TRNS, TRNS, \
TRNS,TRNS,TRNS, TRNS, TRNS,TRNS,TRNS,TRNS),
};
/*
* Fn action definition
*/
const uint16_t PROGMEM fn_actions[] = {
[0] = ACTION_LAYER_TAP_KEY(1, KC_SPACE),
[1] = ACTION_MODS_KEY(MOD_LSFT, KC_GRV), // tilde
};
- one for arrows on IJKL
- one for arrows on HJKL
- one for arrows on WASD
- one for arrows on IJKL
- one for arrows on HJKL
- one for arrows on WASD
You're mentioning IJKL, which is what I use since years, under Emacs. (Basically I never liked Emacs' PBNF so I came up with something that seemed logical to me (an inverted T arrow located on the "home position" but whatever...).
Do you have idea which keyboard/software/layout did use that idea first: I mean, the inverted T arrow located with three of your fingers already on the correct keys?
(so that would be IJKL on QWERTY and CHTN on Dvorak etc.)
Great idea for your layout btw: HHKB here so obviously I think 60% is all that's needed :))
(EDIT: Wikipedia says that one of the earliest game to use IJKL was Loderunner in 1983... I'm old enough to remember playing Loderunner but I didn't remember that it used IJKL. Now I wonder if GH can come up with other "famous" use of IJKL)
I'm waiting for my first HHKB. I should have it soon. I think SpaceFN could be competitive against the native HHKB layout. One of the things that I did not like about the HHKB was that you had to use your pinky so much (to press Fn). Now this point is moot, as I will be able to use my thumb.
The only way to hit space is to do Fn + b? This overcomplicates the most used key on the keyboard, and slows down typing immensely. I could see it useful in a programming environment, but used in any other scenario - writing, gaming, general use - it is clunky.
How about if you hold space, pause, and then release? i.e. you press the modifier key, pause to think, and change your mind about pressing any keys. It sounds like you might get an unintended space in this instance, unlike a normal Fn key where there is no penalty for a change of mind.
Is there a timeout for keyup to have the space bar register as space? Should there be one?
Only problem I see is accidentally activating a macro in the middle of typing or gaming
Huh!? Are you telling me that there is no standard for Home/End/PgUp/PgDn in VIM?
I have been googling this for one hour and it looks like these shortcuts are commonly used:
$: End
0: Home
B: PgUp
F: PgDn
We cannot use 0 and $: They are already assigned to function keys.
What do VIM users want for Home/End?
Would U/I for Home/End and N/M for PgUp/PgDn be acceptable?
Linux users: I'm looking for help to port SpaceFN to Linux!
Linux users: I'm looking for help to port SpaceFN to Linux!
There's a comment on a recent emacsredux.com blog entry as to how to combine xcape with xmodmap to use Return as Control. xcape seems to be what all the cool kids are using these days ; )
I adapted it to use space instead of Return (by replacing 'Return' by 'space' and 36 by 65) as an additional control:
git clone https://github.com/alols/xcape.git (https://github.com/alols/xcape.git)
cd xcape
make
xmodmap -e 'keycode 65 = 0x1234'
xmodmap -e 'add control = 0x1234'
xmodmap -e 'keycode any = space'
./xcape/xcape -e '0x1234=space'
(note that after the two xmodmap you lose temporarily the ability to enter a space so put the xmodmap+xcape in a script).
And it works. But...
I don't know how robust this is but it doesn't work for me: I type at 90wpm+ easily with bursts above 100. I take it I don't release space fast enough once in a while and hence instead of triggering "space + any letter" I trigger "ctrl+ any letter" which makes it totally unusable for me (like at one point inside my browser I inadvertently selected this entire reply while typing it and then hit another letter and, boom, my reply was gone, replaced by a single letter, and I had to type it again... And overall I kept triggering bogus actions).
I didn't see that issue mentioned in your "CONS" list yet I think it's a gigantic no-no (unless I'm seeing things) :(
AFAICT any fix to that problem would mean that I'd have to either slow down my typing (unacceptable) or slow down when I enter "modifier+ ..." (unacceptable too).
So I have to give up the idea to use space as an additional modifier (unless someone can find a way to solve that issue) and I'll keep using my own method: one the two alt as a regular alt and the other as another modifier.
Remapping a key permanently is easy (xmodmap or console-setup).
Remapping a key so that it is interpreted as one key some times and another key at other times is difficult. It's almost doable with a key in combination to the classical modifiers (Shift, Control, Meta, ISO3...). But what we want to do here is beyond the scope of Linux' keyboard management.
Remapping a key permanently is easy (xmodmap or console-setup).
Indeed. I use xkb to do it.QuoteRemapping a key so that it is interpreted as one key some times and another key at other times is difficult. It's almost doable with a key in combination to the classical modifiers (Shift, Control, Meta, ISO3...). But what we want to do here is beyond the scope of Linux' keyboard management.
Oh I see. Well, then I'll wait for a Linux solution. Meanwhile I'm a not so unhappy camper with my "one Alt which is a real Alt and one Alt which acts as a modifier" :o
Peace.
! spacefn.xmodmap file
! following lines map space key as mode_switch key and assigns a bogus keycode for the space key which we must keep around.
keycode 65 = Mode_switch space space space
keycode anykey = space
! here comes the custom altgr layer:
! rest is up to you, as an example here is my colemak uien keys as arrows when pressed with mode_switch (that is altgr)
! note the third columns. those will be triggered when the key is pressed with mode_switch (=altgr)
! also note the fourth columns. those will be triggered when altgr+shift both pressed. we set them too so that selection by shift+arrows is possible.
! if you want to see your current keymap just execute "xmodmap -pke" and copy paste your required lines from there. then modify the third columns as you wish.
keycode 31 = u U Up Up uacute Uacute
keycode 44 = n N Left Left ntilde Ntilde
keycode 45 = e E Down Down eacute Eacute
keycode 46 = i I Right Right iacute Iacute
# spacefn.sh file
xmodmap spacefn.xmodmap
killall xcape -q
./xcape -e '#65=space' -t 250
$ source ./spacefn.sh
here is how you do it in linux using xcape.
0. we'll let xcape to intercept the space key and let it send altgr key (mode_switch) when it's hold longer than some specified time. then by xmodmap we'll devise a custom altgr layer with our home row cursor keys and what not.
1. make install xcape. this is fairly easy and documented so i wont be explaining. see https://github.com/alols/xcape (https://github.com/alols/xcape).
2. save following as spacefn.xmodmapCode: [Select]! spacefn.xmodmap file
! following lines map space key as mode_switch key and assigns a bogus keycode for the space key which we must keep around.
keycode 65 = Mode_switch space space space
keycode anykey = space
! here comes the custom altgr layer:
! rest is up to you, as an example here is my colemak uien keys as arrows when pressed with mode_switch (that is altgr)
! note the third columns. those will be triggered when the key is pressed with mode_switch (=altgr)
! also note the fourth columns. those will be triggered when altgr+shift both pressed. we set them too so that selection by shift+arrows is possible.
! if you want to see your current keymap just execute "xmodmap -pke" and copy paste your required lines from there. then modify the third columns as you wish.
keycode 31 = u U Up Up uacute Uacute
keycode 44 = n N Left Left ntilde Ntilde
keycode 45 = e E Down Down eacute Eacute
keycode 46 = i I Right Right iacute Iacute
3. here is a little script starting/restarting xcape in the background. lets call it spacefn.sh. note the -t 250 option. play with that value as to your liking. see xcape for the explanation. again very simple to understand.Code: [Select]# spacefn.sh file
xmodmap spacefn.xmodmap
killall xcape -q
./xcape -e '#65=space' -t 250
4. execute spacefn.sh to activate your spacefn layout.Code: [Select]$ source ./spacefn.sh
5. enjoy.
i tried having the space key as a dual modifier key before but didn't like it then. but lately with xcape and by playing with its -t value i am fairly comfortable with it right about now.
@spiceBar: ah! that post i entirely missed. you're right. as a slow typer it's only suitable for me i guess. although i must say my rollover error rate is 5% and even that is very annoying. i'll see what can be done.
But let's say the rollover problem was solved.
Have you been using SpaceFN for enough time? Do you have an opinion on how it would work for you?
But let's say the rollover problem was solved.
Have you been using SpaceFN for enough time? Do you have an opinion on how it would work for you?
i have been playing with dual modifier keys and xcape for a few weeks (and before that with ergodox layers). i was using the tab as a modifier, after seeing your topic here on the forum i thought why not the space key again. i'd tried that idea in the beginning but it didn't go well. this time i tried to persist more. so it's the 3rd. day today and i think yeah, i'm going to stick with it. space as the modifier is much much natural than the tab or any other key in a standart layout keyboard. especially while coding where the rollover problem doesn't propagate much it is godsent.
But let's say the rollover problem was solved.
Have you been using SpaceFN for enough time? Do you have an opinion on how it would work for you?
i have been playing with dual modifier keys and xcape for a few weeks (and before that with ergodox layers). i was using the tab as a modifier, after seeing your topic here on the forum i thought why not the space key again. i'd tried that idea in the beginning but it didn't go well. this time i tried to persist more. so it's the 3rd. day today and i think yeah, i'm going to stick with it. space as the modifier is much much natural than the tab or any other key in a standart layout keyboard. especially while coding where the rollover problem doesn't propagate much it is godsent.
Yes, it's a pity that adapting it to Linux is not as straightforward as it should be, especially since the idea to use home row keys (HJKL) has its origins in Unix.
I can tell you that Linux is not forgotten. I have two Linux boxes and a Mac around me here, and no Windows box at all. So I definitely need a Linux version of SpaceFN as well.
I think I could write a Linux utility to implement SpaceFN, I have the skills. It's just that I don't have enough time.
Maybe the sources of xcape or AutoKey could be used as a starting point. xcape seems to be the best bet (AutoKey is buggy).
I hope someone will jump in and help us.
But let's say the rollover problem was solved.
Have you been using SpaceFN for enough time? Do you have an opinion on how it would work for you?
i have been playing with dual modifier keys and xcape for a few weeks (and before that with ergodox layers). i was using the tab as a modifier, after seeing your topic here on the forum i thought why not the space key again. i'd tried that idea in the beginning but it didn't go well. this time i tried to persist more. so it's the 3rd. day today and i think yeah, i'm going to stick with it. space as the modifier is much much natural than the tab or any other key in a standart layout keyboard. especially while coding where the rollover problem doesn't propagate much it is godsent.
Yes, it's a pity that adapting it to Linux is not as straightforward as it should be, especially since the idea to use home row keys (HJKL) has its origins in Unix.
I can tell you that Linux is not forgotten. I have two Linux boxes and a Mac around me here, and no Windows box at all. So I definitely need a Linux version of SpaceFN as well.
I think I could write a Linux utility to implement SpaceFN, I have the skills. It's just that I don't have enough time.
Maybe the sources of xcape or AutoKey could be used as a starting point. xcape seems to be the best bet (AutoKey is buggy).
I hope someone will jump in and help us.
i'm indeed looking at it right now, once i figure out the exact mechanics of the rollover thing it'd be fairly easy to implement. will keep you posted. nice weekend project indeed.
You may find reading this thread useful:
http://geekhack.org/index.php?topic=41685.0
Hasu talks a little bit about how rollover must be managed.
I think a number of clever optimizations can be found, which would eventually feel like magic.
One thing I have not been seen discussed is a way for the keyboard to understand that the user has begun typing normal text. When it detects this, it could make better decisions: space in this case should have a lower probability to be interpreted as a modifier (by changing timing variables). When the flow of text stops, space goes back to a higher probability to be a modifier. Indeed, you don't use navigation keys in the flow of typing text. You always pause (even if it's just for a split of a second) after typing before you use an arrow or a function key.
This thing could be fine-tuned to perfection.
You may find reading this thread useful:
http://geekhack.org/index.php?topic=41685.0
Hasu talks a little bit about how rollover must be managed.
I think a number of clever optimizations can be found, which would eventually feel like magic.
One thing I have not been seen discussed is a way for the keyboard to understand that the user has begun typing normal text. When it detects this, it could make better decisions: space in this case should have a lower probability to be interpreted as a modifier (by changing timing variables). When the flow of text stops, space goes back to a higher probability to be a modifier. Indeed, you don't use navigation keys in the flow of typing text. You always pause (even if it's just for a split of a second) after typing before you use an arrow or a function key.
This thing could be fine-tuned to perfection.
We've had SpaceFN functionality in products for over 20 years, and it's worked very well, but I don't think it's possible to completely eliminate the rollover problem. It's just something you learn to live with.
The Spacebar is very valuable real estate. It's the most frequently used key and the only key that both hands can reach without moving out of home position. Messing with a key that prominent is bound to cause problems -- I'm still surprised at how few those problems are, but they remain.
If you can adjust your typing technique slightly to work around the rollover, you're golden.
However, in exploring alternatives, I believe that another approach yields comparable results, without impacting the functionality of the Spacebar...
If you apply the Dual Modifier approach to Caps Lock and Enter (or the Return key on Mac), you get the same benefits and access to FN from both hands, while retaining full Spacebar functionality. Caps Lock and Enter are used much less frequently, so rollover becomes much less of an issue.
Just IMHO. Carry on... :-)
We've had SpaceFN functionality in products for over 20 years, and it's worked very well, but I don't think it's possible to completely eliminate the rollover problem. It's just something you learn to live with.
The Spacebar is very valuable real estate. It's the most frequently used key and the only key that both hands can reach without moving out of home position. Messing with a key that prominent is bound to cause problems -- I'm still surprised at how few those problems are, but they remain.
If you can adjust your typing technique slightly to work around the rollover, you're golden.
However, in exploring alternatives, I believe that another approach yields comparable results, without impacting the functionality of the Spacebar...
If you apply the Dual Modifier approach to Caps Lock and Enter (or the Return key on Mac), you get the same benefits and access to FN from both hands, while retaining full Spacebar functionality. Caps Lock and Enter are used much less frequently, so rollover becomes much less of an issue.
Just IMHO. Carry on... :-)
How far did you go in your attempts to eliminate the rollover problem?
One thing I have not been seen discussed is a way for the keyboard to understand that the user has begun typing normal text. When it detects this, it could make better decisions: space in this case should have a lower probability to be interpreted as a modifier (by changing timing variables). When the flow of text stops, space goes back to a higher probability to be a modifier. Indeed, you don't use navigation keys in the flow of typing text. You always pause (even if it's just for a split of a second) after typing before you use an arrow or a function key.
This thing could be fine-tuned to perfection.
I'm wondering if you have tried heuristics like the one I have described above.
The space bar is so convenient, and you know it, that it's hard to consider anything else once you have tried it. I have a half baked implementation on my Mac done with KeyRemap4MacBook, it solves the rollover problem with a simple delay (space cannot be a modifier on the first 150ms after it's pressed), but it already works so well that I have been able to be productive in the first hour of use and after 3 weeks I'm not tired of it. Actually I want more of it.
I concede that if I did not know that space can be used as an Fn key, I would say that CapsLock and Enter are pretty good candidates.
But the space bar is always under your thumbs. CapsLock and Enter are NEVER under any of my fingers unless I reach for them. And I prefer to generate a space by accident than an Enter.
It may be hard enough to convince people that they can hold the space bar down without doing any damage. I'd rather not be the one trying to convince them they can do the same with Enter... :)
It's crazy that I find myself advocating the use of space as a modifier to the guy who pioneered it. Hey, have you lost the faith? ;-)
We've had SpaceFN functionality in products for over 20 years, and it's worked very well, but I don't think it's possible to completely eliminate the rollover problem. It's just something you learn to live with.
The Spacebar is very valuable real estate. It's the most frequently used key and the only key that both hands can reach without moving out of home position. Messing with a key that prominent is bound to cause problems -- I'm still surprised at how few those problems are, but they remain.
If you can adjust your typing technique slightly to work around the rollover, you're golden.
However, in exploring alternatives, I believe that another approach yields comparable results, without impacting the functionality of the Spacebar...
If you apply the Dual Modifier approach to Caps Lock and Enter (or the Return key on Mac), you get the same benefits and access to FN from both hands, while retaining full Spacebar functionality. Caps Lock and Enter are used much less frequently, so rollover becomes much less of an issue.
Just IMHO. Carry on... :-)
How far did you go in your attempts to eliminate the rollover problem?
Pretty far...
I tried a number of different approaches, and they each had their quirks. Ultimately, I settled on the one that worked best for one-handed typing -- which admittedly is a different application from what you're proposing.One thing I have not been seen discussed is a way for the keyboard to understand that the user has begun typing normal text. When it detects this, it could make better decisions: space in this case should have a lower probability to be interpreted as a modifier (by changing timing variables). When the flow of text stops, space goes back to a higher probability to be a modifier. Indeed, you don't use navigation keys in the flow of typing text. You always pause (even if it's just for a split of a second) after typing before you use an arrow or a function key.
This thing could be fine-tuned to perfection.
I'm wondering if you have tried heuristics like the one I have described above.
I didn't try that one, but I'd guess that as you get more proficient, there will be fewer pauses, and your heuristics may break down.
You may also find that the heuristics are different for experts vs. novices, which would really complicate things.
The space bar is so convenient, and you know it, that it's hard to consider anything else once you have tried it. I have a half baked implementation on my Mac done with KeyRemap4MacBook, it solves the rollover problem with a simple delay (space cannot be a modifier on the first 150ms after it's pressed), but it already works so well that I have been able to be productive in the first hour of use and after 3 weeks I'm not tired of it. Actually I want more of it.
If it works for you and you're happy with it, there's no reason why you shouldn't use it.
I'm just saying that it's unlikely that ALL the problems can be completely eliminated.
For example, your 150ms timeout works out to 80wpm. If your burst rate with spaces is slower than that, then you'll get rollover interference while typing. If you get very proficient, and your pause time drops below 150ms, you'll get rollover intereference using FN.
You may be able to tune it to each particular user, but that increases complexity.
I concede that if I did not know that space can be used as an Fn key, I would say that CapsLock and Enter are pretty good candidates.
But the space bar is always under your thumbs. CapsLock and Enter are NEVER under any of my fingers unless I reach for them. And I prefer to generate a space by accident than an Enter.
Point taken.
Given the choice, I'd just as soon sacrifice CapsLock altogether and put a simple Fn key there. It may not be under my thumbs, but I can get to it REALLY fast.
It may be hard enough to convince people that they can hold the space bar down without doing any damage. I'd rather not be the one trying to convince them they can do the same with Enter... :)
Well, with the Spacebar, the penalty for errors is lower, but I think the probability of errors is higher.
It's crazy that I find myself advocating the use of space as a modifier to the guy who pioneered it. Hey, have you lost the faith? ;-)
Nice of you to say that :) but I have a lot of arrow holes in my back, so I can tell you it's a long journey for these kinds of ideas.
Also, I don't want to dissuade you from what you're doing. I'm just passing along my personal experience, and adding some data points. This may all be a matter of personal choice.
ok this is my 4th day today using the space as a modifier for ijkl arrows and i am not going back.
@spiceBar hold tight for a linux solution implementing your heuristics ideas. i spent yesterday dabbling in xlib, it's possible to implement everything you talked in your OP but afaik not with one clean single utility. it'll be a mismash of xmodmap and a background service like xcape alas. to my horror x11 is not even on par with good old win32 api when it comes to capability.
ok this is my 4th day today using the space as a modifier for ijkl arrows and i am not going back.
@spiceBar hold tight for a linux solution implementing your heuristics ideas. i spent yesterday dabbling in xlib, it's possible to implement everything you talked in your OP but afaik not with one clean single utility. it'll be a mismash of xmodmap and a background service like xcape alas. to my horror x11 is not even on par with good old win32 api when it comes to capability.
ok this is my 4th day today using the space as a modifier for ijkl arrows and i am not going back.
@spiceBar hold tight for a linux solution implementing your heuristics ideas. i spent yesterday dabbling in xlib, it's possible to implement everything you talked in your OP but afaik not with one clean single utility. it'll be a mismash of xmodmap and a background service like xcape alas. to my horror x11 is not even on par with good old win32 api when it comes to capability.
I have downloaded the source code of xcape, and it's only ~500 lines of C. And most of it is housekeeping.
I will have to spend some of my time on it... At least to assess if it can be modified to do the job or not.
One thing I have not been seen discussed is a way for the keyboard to understand that the user has begun typing normal text. When it detects this, it could make better decisions: space in this case should have a lower probability to be interpreted as a modifier (by changing timing variables). When the flow of text stops, space goes back to a higher probability to be a modifier. Indeed, you don't use navigation keys in the flow of typing text. You always pause (even if it's just for a split of a second) after typing before you use an arrow or a function key.
This thing could be fine-tuned to perfection.
I'm wondering if you have tried heuristics like the one I have described above.
I didn't try that one, but I'd guess that as you get more proficient, there will be fewer pauses, and your heuristics may break down.
You may also find that the heuristics are different for experts vs. novices, which would really complicate things.
My job is computer chess, so I tend to have a high threshold on what I call "complicated". :)
I guess the complexity limiter is going to be the limited RAM on keyboard controllers.
The space bar is so convenient, and you know it, that it's hard to consider anything else once you have tried it. I have a half baked implementation on my Mac done with KeyRemap4MacBook, it solves the rollover problem with a simple delay (space cannot be a modifier on the first 150ms after it's pressed), but it already works so well that I have been able to be productive in the first hour of use and after 3 weeks I'm not tired of it. Actually I want more of it.
If it works for you and you're happy with it, there's no reason why you shouldn't use it.
I'm just saying that it's unlikely that ALL the problems can be completely eliminated.
For example, your 150ms timeout works out to 80wpm. If your burst rate with spaces is slower than that, then you'll get rollover interference while typing. If you get very proficient, and your pause time drops below 150ms, you'll get rollover intereference using FN.
You may be able to tune it to each particular user, but that increases complexity.
It works but I'm not happy with it. It's just that KeyRemap4MacBook doesn't offer any other mean of dealing with rollover.
The 150ms timeout protects perfectly against rollover at very high typing speeds. Space cannot be interpreted as a modifier in the first 150ms after it is pressed, and the next key pressed within 150ms prevents spaceso you can type as fast as you want, no accidental Fn will be generated.
If you type slowly, you would have to keep space pressed for more than 150ms AND the next key would have to be pressed before space is released to get an accidental Fn.
In practice, what's wrong with this simple timeout idea is that you must press and hold space well before you press the next key to get the corresponding Fn action. You must hold it 150ms before you press the next key, which is short (approx. 1/7 of a second), but long enough that you need to be careful about it.
For example, I know that I must press and hold space a split of a second before I press the next key when I want an Fn layer action. Day after day I have adapted to this. It's a crude mechanism, and eventually it will be replaced, but so far it's very usable.
A user-independant heuristic would be to detect burst of typed text and dynamically make this timeout longer to reduce the risk of accidental Fn. When the user has stopped typing, the timeout could be significantly reduced.
A user-dependant heuristic would be to detect the error rate to adjust the timeout. How can we detect the error rate? When the user is typing, I think it's pretty safe to assume that he will use the Backspace key to correct a typo. If the last two characters typed have involved a space, we can gather some information.
So just with a crude timeout, adapting to what the user is doing or to the user itself may be possible. I'm not even saying that this timeout idea is correct, a correct implementation will be much smarter.
It's crazy that I find myself advocating the use of space as a modifier to the guy who pioneered it. Hey, have you lost the faith? ;-)
Nice of you to say that :) but I have a lot of arrow holes in my back, so I can tell you it's a long journey for these kinds of ideas.
Also, I don't want to dissuade you from what you're doing. I'm just passing along my personal experience, and adding some data points. This may all be a matter of personal choice.
Yes I understand. On one hand, the general public is not going to buy the idea of using space as a modifier, and on the other hand heavy computer users will probably get it but they are going to be extremely picky and will not have much tolerance for any usability problem.
It's a hard challenge for a limited market.
I find your input valuable. What you say is helping me in the following way:
- It is not completely decided at this time if space can be safely used as a modifier. In spite of the various claims that it can, I should still be worried about it and look out for improvements.
- There are some obvious heuristics that have still not been tried, so there is hope that the use of space as a modifier can be improved further.
And I appreciate very much that you take the time to discuss with us. I don't remember that any other keyboard designer/manufacturer has ever taken the time to comment in such a discussion.
It's like they believe they can spit out the magical keyboard layout without ever seeking input from advanced users. Which gives us horribly designed keyboards, and I refrain from mentioning names because some of them are… popular.
So one reason I dont like some 60%'s is that they have odd layouts of function meaning I can do either one handed combos (usedul for arrowkeys and the like) or only two handed combos (less awkward, more speed)
It works but I'm not happy with it. It's just that KeyRemap4MacBook doesn't offer any other mean of dealing with rollover.
The 150ms timeout protects perfectly against rollover at very high typing speeds. Space cannot be interpreted as a modifier in the first 150ms after it is pressed, and the next key pressed within 150ms prevents spaceso you can type as fast as you want, no accidental Fn will be generated.
If you type slowly, you would have to keep space pressed for more than 150ms AND the next key would have to be pressed before space is released to get an accidental Fn.
In practice, what's wrong with this simple timeout idea is that you must press and hold space well before you press the next key to get the corresponding Fn action. You must hold it 150ms before you press the next key, which is short (approx. 1/7 of a second), but long enough that you need to be careful about it.
What's interesting about your approach is that it protects fast typists while endangering slow ones. Normally, it's the other way around.
It also speed constrains its main feature, which works against the users who are most likely to find it attractive -- expert users.
For example, I know that I must press and hold space a split of a second before I press the next key when I want an Fn layer action. Day after day I have adapted to this. It's a crude mechanism, and eventually it will be replaced, but so far it's very usable.
Crude mechanisms can be surprisingly effective. Sometimes it's easier for the user to adapt to the system, than vice versa.
Another thing to keep in mind...
If your heuristic is not perfect, but also so complicated that the user can't tell what they need to do to make it work reliably, it becomes unpredictable. Cruder approaches are generally very predictable, and therefore more easy to adapt to.
And I appreciate very much that you take the time to discuss with us. I don't remember that any other keyboard designer/manufacturer has ever taken the time to comment in such a discussion.
Well, it's their loss. The community here is an incredible resource for information, ideas, and opinion. If they choose not to participate, perhaps they're not as interested in this stuff as they would have you believe.
Other cons:
- key chords are awkward, e.g. Control+Left to skip words, Shift+Control+Left to select words.
- keeping the space bar pressed to move around documents can be tiring, more so on keyboards with harder keys.
- no number pad layer.
I don't want to sound dismissive, but a keyboard layout can't be squeezed more than a tenkeyless without affecting effective usage, because lots of different uses have accumulated over all extra keys throughout the years. Even obsolete keys -- like Screen Lock -- are useful because users can map them for their own use without interfering with existing applications.
These days I have given attention to the issue, and I do agree that having movement keys with chords in a 60% is more beneficial than separated keys in a tenkeyless.
I think it's time for me to reiterate that I'm not planning to rely exclusively on this approach to manage rollover.
And for exactly the reason you mention: it works against expert users.
The only way for KeyRemap4MacBook to prevent rollover is to have this timing. The timing says that when a dual role modifier (in my case it is space) is pressed, it cannot be considered as a modifier until some amount of time has elapsed. You can change this in the KeyRemap4MacBook settings, but it is basically a static value.
I do not suggest that this simple trick is the solution to eliminate rollover.
I think that you will agree that the correct, basic way to eliminate rollover is to look at the sequence of KeyUp/KeyDown events.
This is rollover (space character followed by other character):
space -------------------------------
other -------------------------------------
This is space used as a modifier (combination of space+other):
space ---------------------------------------------------------------------
other --------------------------
In the "graphic" above, time goes from left to right, an hyphen means that the corresponding key is down. The graphic is supposed to represent a small duration, in the order of a quarter of a second.
What I hope is that an algorithm based on the KeyUp/KeyDown sequences and their timings, enhanced by several heuristics that will involve context-dependant timers, will give a satisfying low error rate.
I think it's time for me to reiterate that I'm not planning to rely exclusively on this approach to manage rollover.
And for exactly the reason you mention: it works against expert users.
The only way for KeyRemap4MacBook to prevent rollover is to have this timing. The timing says that when a dual role modifier (in my case it is space) is pressed, it cannot be considered as a modifier until some amount of time has elapsed. You can change this in the KeyRemap4MacBook settings, but it is basically a static value.
I do not suggest that this simple trick is the solution to eliminate rollover.
I think that you will agree that the correct, basic way to eliminate rollover is to look at the sequence of KeyUp/KeyDown events.
This is rollover (space character followed by other character):
space -------------------------------
other -------------------------------------
This is space used as a modifier (combination of space+other):
space ---------------------------------------------------------------------
other --------------------------
In the "graphic" above, time goes from left to right, an hyphen means that the corresponding key is down. The graphic is supposed to represent a small duration, in the order of a quarter of a second.
What I hope is that an algorithm based on the KeyUp/KeyDown sequences and their timings, enhanced by several heuristics that will involve context-dependant timers, will give a satisfying low error rate.
Apologies for walking into the middle of this conversation, because I didn't read the whole thread. But I thought I'd chime in on this because I've been using the dual-role modifiers (on space and on backspace on my ergodox), and this (the algorithm for determining which is which) is my big problem with it. I should mention that I'm using hasu's TMK firmware that can do this. I believe his works the way you describe here: it takes into account BOTH the sequence of keydown+keyup events, AND a timeout threshold. I type (and use my hotkeys) really fast and this doesn't work for me. I have to consciously slow down and hold the space key much longer than I normally would (I think it's like 200ms). I think I'd prefer it to be ONLY the timeout and have it be a relatively short threshold. Just my 2cents.
I tried using Space as a Fn key recently and it was not for me. When I type very quickly I was getting function key presses in with the normal typing as well as sometimes having space not register. I think that since the space bar is hit more often than any other key it is not a good match as a Fn key.
I really wanted it to work because I thought it would be great, but when actually using it, I found it to be a hinder.
The main reason I wanted to use it was to have a numpad on the left side of my keyboard that I only needed my left hand to activate and use. Instead of using space, I now use the caps lock key with the same principle as discussed here with the space key. We will see how that goes...
Current Fn layer on my TKL:
(Attachment Link)
I tried using Space as a Fn key recently and it was not for me. When I type very quickly I was getting function key presses in with the normal typing as well as sometimes having space not register. I think that since the space bar is hit more often than any other key it is not a good match as a Fn key.
I really wanted it to work because I thought it would be great, but when actually using it, I found it to be a hinder.
The main reason I wanted to use it was to have a numpad on the left side of my keyboard that I only needed my left hand to activate and use. Instead of using space, I now use the caps lock key with the same principle as discussed here with the space key. We will see how that goes...
Current Fn layer on my TKL:
(Attachment Link)
I guess that you have been using a software implementation. Which one?
The software versions of SpaceFN are not as good as the hardware ones, which use Hasu's firmware. Hasu has worked for much longer on it, and I must say that that it works flawlessly, at least I never get unwanted function key presses, and space always register.
But unfortunately it's hard to get the same accuracy with a software simulation.
I tried using Space as a Fn key recently and it was not for me. When I type very quickly I was getting function key presses in with the normal typing as well as sometimes having space not register. I think that since the space bar is hit more often than any other key it is not a good match as a Fn key.
I really wanted it to work because I thought it would be great, but when actually using it, I found it to be a hinder.
The main reason I wanted to use it was to have a numpad on the left side of my keyboard that I only needed my left hand to activate and use. Instead of using space, I now use the caps lock key with the same principle as discussed here with the space key. We will see how that goes...
Current Fn layer on my TKL:
(Attachment Link)
I guess that you have been using a software implementation. Which one?
The software versions of SpaceFN are not as good as the hardware ones, which use Hasu's firmware. Hasu has worked for much longer on it, and I must say that that it works flawlessly, at least I never get unwanted function key presses, and space always register.
But unfortunately it's hard to get the same accuracy with a software simulation.
Not software based. I was using qaz's firmware (http://geekhack.org/index.php?topic=51252.msg1127412#msg1127412). I have not tried it with Hasu's firmware, but I suspect that typing at full speed will have similar results. I think it have something to do with the fact that I start pressing another key as I release the spacebar. If the firmware is not instant with removing the Fn layer, I will have problems...
I tried using Space as a Fn key recently and it was not for me. When I type very quickly I was getting function key presses in with the normal typing as well as sometimes having space not register. I think that since the space bar is hit more often than any other key it is not a good match as a Fn key.
I really wanted it to work because I thought it would be great, but when actually using it, I found it to be a hinder.
The main reason I wanted to use it was to have a numpad on the left side of my keyboard that I only needed my left hand to activate and use. Instead of using space, I now use the caps lock key with the same principle as discussed here with the space key. We will see how that goes...
Current Fn layer on my TKL:
(Attachment Link)
I guess that you have been using a software implementation. Which one?
The software versions of SpaceFN are not as good as the hardware ones, which use Hasu's firmware. Hasu has worked for much longer on it, and I must say that that it works flawlessly, at least I never get unwanted function key presses, and space always register.
But unfortunately it's hard to get the same accuracy with a software simulation.
Not software based. I was using qaz's firmware (http://geekhack.org/index.php?topic=51252.msg1127412#msg1127412). I have not tried it with Hasu's firmware, but I suspect that typing at full speed will have similar results. I think it have something to do with the fact that I start pressing another key as I release the spacebar. If the firmware is not instant with removing the Fn layer, I will have problems...
Pressing another key while releasing space is called rollover, and it's taken into account by firmwares that allow the use of dual role modifiers.
There are some posts about this in the current thread.
Would you be able to try Hasu's firmware (TMK)? Hasu has done a lot of work to correctly handle rollover, and it works really well in my experience.
It goes even beyond rollover and handles plenty of special cases transparently. Personally I have not been able to fault it.
Here is a link to the firmware:
https://github.com/tmk/tmk_keyboard
I am really interested in your experience with Hasu's firmware, if you can try it. Thank you in advance!
I tried using Space as a Fn key recently and it was not for me. When I type very quickly I was getting function key presses in with the normal typing as well as sometimes having space not register. I think that since the space bar is hit more often than any other key it is not a good match as a Fn key.
I really wanted it to work because I thought it would be great, but when actually using it, I found it to be a hinder.
The main reason I wanted to use it was to have a numpad on the left side of my keyboard that I only needed my left hand to activate and use. Instead of using space, I now use the caps lock key with the same principle as discussed here with the space key. We will see how that goes...
Current Fn layer on my TKL:
(Attachment Link)
I guess that you have been using a software implementation. Which one?
The software versions of SpaceFN are not as good as the hardware ones, which use Hasu's firmware. Hasu has worked for much longer on it, and I must say that that it works flawlessly, at least I never get unwanted function key presses, and space always register.
But unfortunately it's hard to get the same accuracy with a software simulation.
Not software based. I was using qaz's firmware (http://geekhack.org/index.php?topic=51252.msg1127412#msg1127412). I have not tried it with Hasu's firmware, but I suspect that typing at full speed will have similar results. I think it have something to do with the fact that I start pressing another key as I release the spacebar. If the firmware is not instant with removing the Fn layer, I will have problems...
Pressing another key while releasing space is called rollover, and it's taken into account by firmwares that allow the use of dual role modifiers.
There are some posts about this in the current thread.
Would you be able to try Hasu's firmware (TMK)? Hasu has done a lot of work to correctly handle rollover, and it works really well in my experience.
It goes even beyond rollover and handles plenty of special cases transparently. Personally I have not been able to fault it.
Here is a link to the firmware:
https://github.com/tmk/tmk_keyboard
I am really interested in your experience with Hasu's firmware, if you can try it. Thank you in advance!
Yes, I can give it a shot. Hopefully this weekend. I also want to do some more troubleshooting with dfu-programmer because it failed on the hex file I got to work with Flip, so I wanted to spend some time trying different hex files to see if I can figure out why dfu-programmer failed...
I have not tried to use TMK yet, so there will be a bit of a learning curve to figure out how to build my layout, but I am a pretty quick study, so I should be fine...
I will try to post back by the beginning of the week...
I tried using Space as a Fn key recently and it was not for me. When I type very quickly I was getting function key presses in with the normal typing as well as sometimes having space not register. I think that since the space bar is hit more often than any other key it is not a good match as a Fn key.
I really wanted it to work because I thought it would be great, but when actually using it, I found it to be a hinder.
The main reason I wanted to use it was to have a numpad on the left side of my keyboard that I only needed my left hand to activate and use. Instead of using space, I now use the caps lock key with the same principle as discussed here with the space key. We will see how that goes...
Current Fn layer on my TKL:
(Attachment Link)
I guess that you have been using a software implementation. Which one?
The software versions of SpaceFN are not as good as the hardware ones, which use Hasu's firmware. Hasu has worked for much longer on it, and I must say that that it works flawlessly, at least I never get unwanted function key presses, and space always register.
But unfortunately it's hard to get the same accuracy with a software simulation.
Not software based. I was using qaz's firmware (http://geekhack.org/index.php?topic=51252.msg1127412#msg1127412). I have not tried it with Hasu's firmware, but I suspect that typing at full speed will have similar results. I think it have something to do with the fact that I start pressing another key as I release the spacebar. If the firmware is not instant with removing the Fn layer, I will have problems...
Pressing another key while releasing space is called rollover, and it's taken into account by firmwares that allow the use of dual role modifiers.
There are some posts about this in the current thread.
Would you be able to try Hasu's firmware (TMK)? Hasu has done a lot of work to correctly handle rollover, and it works really well in my experience.
It goes even beyond rollover and handles plenty of special cases transparently. Personally I have not been able to fault it.
Here is a link to the firmware:
https://github.com/tmk/tmk_keyboard
I am really interested in your experience with Hasu's firmware, if you can try it. Thank you in advance!
Yes, I can give it a shot. Hopefully this weekend. I also want to do some more troubleshooting with dfu-programmer because it failed on the hex file I got to work with Flip, so I wanted to spend some time trying different hex files to see if I can figure out why dfu-programmer failed...
I have not tried to use TMK yet, so there will be a bit of a learning curve to figure out how to build my layout, but I am a pretty quick study, so I should be fine...
I will try to post back by the beginning of the week...
Great! What keyboard are you using?
I tried using Space as a Fn key recently and it was not for me. When I type very quickly I was getting function key presses in with the normal typing as well as sometimes having space not register. I think that since the space bar is hit more often than any other key it is not a good match as a Fn key.
I really wanted it to work because I thought it would be great, but when actually using it, I found it to be a hinder.
The main reason I wanted to use it was to have a numpad on the left side of my keyboard that I only needed my left hand to activate and use. Instead of using space, I now use the caps lock key with the same principle as discussed here with the space key. We will see how that goes...
Current Fn layer on my TKL:
(Attachment Link)
I guess that you have been using a software implementation. Which one?
The software versions of SpaceFN are not as good as the hardware ones, which use Hasu's firmware. Hasu has worked for much longer on it, and I must say that that it works flawlessly, at least I never get unwanted function key presses, and space always register.
But unfortunately it's hard to get the same accuracy with a software simulation.
Not software based. I was using qaz's firmware (http://geekhack.org/index.php?topic=51252.msg1127412#msg1127412). I have not tried it with Hasu's firmware, but I suspect that typing at full speed will have similar results. I think it have something to do with the fact that I start pressing another key as I release the spacebar. If the firmware is not instant with removing the Fn layer, I will have problems...
Pressing another key while releasing space is called rollover, and it's taken into account by firmwares that allow the use of dual role modifiers.
There are some posts about this in the current thread.
Would you be able to try Hasu's firmware (TMK)? Hasu has done a lot of work to correctly handle rollover, and it works really well in my experience.
It goes even beyond rollover and handles plenty of special cases transparently. Personally I have not been able to fault it.
Here is a link to the firmware:
https://github.com/tmk/tmk_keyboard
I am really interested in your experience with Hasu's firmware, if you can try it. Thank you in advance!
Yes, I can give it a shot. Hopefully this weekend. I also want to do some more troubleshooting with dfu-programmer because it failed on the hex file I got to work with Flip, so I wanted to spend some time trying different hex files to see if I can figure out why dfu-programmer failed...
I have not tried to use TMK yet, so there will be a bit of a learning curve to figure out how to build my layout, but I am a pretty quick study, so I should be fine...
I will try to post back by the beginning of the week...
Great! What keyboard are you using?
Filco tkl with a hid liberation device.
TMK was initially loaded on my HID by the previous owner, so I know that's not a problem. I have looked at TMK and I liked what I saw, but wanted to try the UI first.
I will have to change the default spaceFn layout I'm sure. Right now I just want a numpad on my left hand home row. On a 60% I will want the arrows on the right hand and I would like to use spaceFn if I can.
TMK was initially loaded on my HID by the previous owner, so I know that's not a problem. I have looked at TMK and I liked what I saw, but wanted to try the UI first.
I will have to change the default spaceFn layout I'm sure. Right now I just want a numpad on my left hand home row. On a 60% I will want the arrows on the right hand and I would like to use spaceFn if I can.
Maybe you can try the provided SpaceFn layout first and see if you still have problems with rollover of space and other keys. No need to go further if it does not work for you.
If it solves the rollover problems, you know you can rather easily modify the layout and add the number pad.
maybe a good idea would be to activate the number pad with another key, not space. So the number pad would be in another layer (TMK supports up to 8 layers) and you would not have to change the SpaceFN layout at all.
If you put the numpad in the SpaceFN layout (activated by pressing and holding space), you are going to overload X, C and V. If you do, you will not be able to keep space pressed when you copy/paste text, and it's a pity because it is very convenient.
So I suggest that you activate the numpad layout by pressing and holding a key on the right hand, for example Enter or backslash.
I don't want to hijack this thread, but since I posted my first attempt of using the caps lock as a Fn key, I wanted to post back an improvement that I found helpful.
I plan to use something closer to what I did originally when I get spaceFn working cause then I won't have to move my fingers from the nubs. If you just want to get a numpad on a TKL, the following feels pretty natural. Moving the one key over actually makes it easy for the brain to remember that its a numpad (for me anyway).
(Attachment Link)
Keep in mind that I mainly type IP addresses and floats when I am typing numbers, so those are the keys I needed most.
I will post back once I have had a chance to build the spaceFn layout in TMK and test it...
I don't want to hijack this thread, but since I posted my first attempt of using the caps lock as a Fn key, I wanted to post back an improvement that I found helpful.
I plan to use something closer to what I did originally when I get spaceFn working cause then I won't have to move my fingers from the nubs. If you just want to get a numpad on a TKL, the following feels pretty natural. Moving the one key over actually makes it easy for the brain to remember that its a numpad (for me anyway).
(Attachment Link)
Keep in mind that I mainly type IP addresses and floats when I am typing numbers, so those are the keys I needed most.
I will post back once I have had a chance to build the spaceFn layout in TMK and test it...
Hasu's TMK firmware allows you to do this.
I'm even thinking that this should maybe be part of the standard SpaceFN layout, but with the numpad on the right hand, where the inverted T cluster already is. So no need to move the hand either to type numbers... I would use the "7 8 9" keys for 7, 8 and 9, and then "UIO", "JKL" and M and the comma.
So... Have you been able to try Hasu's firmware?
this is incredible. thanks!
using the spacebar as fn in tmkfirmware...this is incredible. thanks!
What is incredible?
PS: I like your signature.
using the spacebar as fn in tmkfirmware...this is incredible. thanks!
What is incredible?
PS: I like your signature.
Yes I tried it and it works great. I am used to the poker arrows and layout so I was thinking that maybe I would utilise the space/fn on the poker layout and change the poker layout FN to alt.
it is actually a gh60 rev.a that I am flashing tmk firmware to. poker layout....
I am building a friendly layout editor in c# based on hasu's tmk firmware for the gh60.
it is actually a gh60 rev.a that I am flashing tmk firmware to. poker layout....
I am building a friendly layout editor in c# based on hasu's tmk firmware for the gh60.
A friendly editor for Hasu's firmware, a very nice idea!
I think it would be very easy for this editor to be usable for all variants of Hasu's firmware, including his HHKB mod, the PS/2->USB converter, the HID liberation and so on.
Are you writing it under Windows or Linux? I can test it for you under Linux and Mac OS if you want. I think Winforms is supported under Linux, but I'm not sure about Mac OS. The few projects I have written in C# I wrote them under Linux with GTK# as the GUI frontend and then tested them on Windows and Mac OS. It was 3 years ago. I know C# + GTK# is really portable, I'm not sure about C# + Winforms.
I have a GH60 rev.A, several PS/2->USB adapters and Hasu's HHKB mod. So I can test for all these variants.
it is actually a gh60 rev.a that I am flashing tmk firmware to. poker layout....
I am building a friendly layout editor in c# based on hasu's tmk firmware for the gh60.
A friendly editor for Hasu's firmware, a very nice idea!
I think it would be very easy for this editor to be usable for all variants of Hasu's firmware, including his HHKB mod, the PS/2->USB converter, the HID liberation and so on.
Are you writing it under Windows or Linux? I can test it for you under Linux and Mac OS if you want. I think Winforms is supported under Linux, but I'm not sure about Mac OS. The few projects I have written in C# I wrote them under Linux with GTK# as the GUI frontend and then tested them on Windows and Mac OS. It was 3 years ago. I know C# + GTK# is really portable, I'm not sure about C# + Winforms.
I have a GH60 rev.A, several PS/2->USB adapters and Hasu's HHKB mod. So I can test for all these variants.
asp.net webservice...
asp.net webservice...
I just wanted to update this thread with pictures of a real SpaceFN keyboard with dedicated keycaps:
(Attachment Link)
(Attachment Link)
The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.
As you can see I'm an AZERTY user. The SpaceFN layout can be implemented on top of any national layout, be it an ANSI or ISO variant.
I have designed the keycaps by creating an SVG file (vector graphics) which has been sent to WASD Keyboards for printing. The legends have a better definition (resolution) than I expected.
The functions of the SpaceFN layer (activated by holding space) are written at the right of the keycaps, centered vertically.
The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.Nice keycaps. :) My opinion is that they aren't needed since the SpaceFN layout is really quite intuitive. :) Do you have custom firmware installed in that Poker, or are you using software like AHK?
The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.Nice keycaps. :) My opinion is that they aren't needed since the SpaceFN layout is really quite intuitive. :) Do you have custom firmware installed in that Poker, or are you using software like AHK?
I've been trying to use SpaceFN + lydell's AHK scripts for work for the past two weeks with both my Poker II and HHKB. I really love the SpaceFN layout. It is really intuitive and comfortable, and it's great that I can use it for any board.
However, I'm having several issues with AHK that might be a deal breaker for me. AHK doesn't work very well with Remote Desktop. I have to exclusively run AHK on either my local box or remote box, but not both. When typing remotely, the lag results in more timing issues than normal. Also, I'm seeing an issue with my work machine where keypresses will be out of whack (Alt is permanently held down) after unlocking my machine. Restarting the AHK script and even AHK does not fix the issue, and I'll have to relogin for things to work again. I haven't had a chance to look into AHK's scripting, so maybe there are ways to address these issues.
I would love to have programmable firmware, but I don't know how to solder, and I would especially be afraid to mess with my HHKB, so this isn't an option for me right now.
You mentioned you are developing a new setup for Poker using its stock programming capabilities, so that will definitely be worth trying, although I won't be able to utilize this for my HHKB.
p.s. Where is your red TEX case? :p
However, I'm having several issues with AHK that might be a deal breaker for me. AHK doesn't work very well with Remote Desktop. I have to exclusively run AHK on either my local box or remote box, but not both. When typing remotely, the lag results in more timing issues than normal.
Also, I'm seeing an issue with my work machine where keypresses will be out of whack (Alt is permanently held down) after unlocking my machine. Restarting the AHK script and even AHK does not fix the issue, and I'll have to relogin for things to work again. I haven't had a chance to look into AHK's scripting, so maybe there are ways to address these issues.
I've been running this for a while using ahk and I had to modify the timeout, it was too short on the original configuration. other than that it works great, preparing myself for a poker2
I just wanted to update this thread with pictures of a real SpaceFN keyboard with dedicated keycaps:
(Attachment Link)
(Attachment Link)
The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.
As you can see I'm an AZERTY user. The SpaceFN layout can be implemented on top of any national layout, be it an ANSI or ISO variant.
I have designed the keycaps by creating an SVG file (vector graphics) which has been sent to WASD Keyboards for printing. The legends have a better definition (resolution) than I expected.
The functions of the SpaceFN layer (activated by holding space) are written at the right of the keycaps, centered vertically.
I just wanted to update this thread with pictures of a real SpaceFN keyboard with dedicated keycaps:
(Attachment Link)
(Attachment Link)
The keyboard is a Poker 2 (MX reds) in a Tex aluminum case.
As you can see I'm an AZERTY user. The SpaceFN layout can be implemented on top of any national layout, be it an ANSI or ISO variant.
I have designed the keycaps by creating an SVG file (vector graphics) which has been sent to WASD Keyboards for printing. The legends have a better definition (resolution) than I expected.
The functions of the SpaceFN layer (activated by holding space) are written at the right of the keycaps, centered vertically.
So by dedicated keycaps you meant the customized ones you ordered from WASD K, didn't you? I was a little confused when I read a real space FN keyboard, because the entire point of Space-FN is precisely that any board can be used to implement it, so there is no such thing like a real FN board.
This SpaceFN idea is nice, it certainly makes better use of under-used thumbs.
It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/
Also for those who don't use left Alt much, this key has potential to be remapped to an Fn key as on most keyboards it can just about reached with the thumb.
Does anyone have other suggestions/remappings for more efficient use of thumbs on a standard keyboard?
Made a version of my rebinder for windows in C# with this layout as a base, not exactly the same though. (can't use AHK, even packaged, anti-cheating software like PunkBuster bans anyone using it)
https://github.com/p3lim/Lackey/tree/SpaceFN
Not exactly sure if I like it yet, I feel like the spacebar lags out behind or something, mostly because I am used to type fast (100+ WPM), and the space comes in too late that what I am used to expect.
Really like how easy it is to use the FN layer though.
I've been using a slightly modified version of this layout on my Filco for a few weeks now. Implemented in firmware on a kitten paw controller. The delay on the spacebar was pretty distracting at first but I don't even notice it now.
Overall I'm really loving it. I'm training myself so hopefully I won't have any trouble adopting a full 60% layout when the GH60s finally arrive. :))
I agree that the space bar is too small on the Filco Minila. But having the space bar act funny scares me.
As it happens, I was doing some thinking ages ago of how to make a smaller keyboard like this. And I discuss what I came up with on my web site, at
http://www.quadibloc.com/comp/kyb0602.htm (http://www.quadibloc.com/comp/kyb0602.htm)
Basically, I decided that there were two relatively little-used keys on the Model M typing area that were even in a symmetrical position, perfect for being repurposed as Fn keys.
The tab key, and the | and \ key.
I have designed another layout called GuiFNOn that one, I'd probably use the pinky for the Fn, not the thumb. (How would I use the thumb for that Fn key without lifting the fingers of my right hand from the home keys?) And, of course, that is the layout (as far as the position of the Fn key goes) that is actually in use by the Poker II keyboard.
I have designed another layout called GuiFNOn that one, I'd probably use the pinky for the Fn, not the thumb. (How would I use the thumb for that Fn key without lifting the fingers of my right hand from the home keys?) And, of course, that is the layout (as far as the position of the Fn key goes) that is actually in use by the Poker II keyboard.
Since the pinky is already being used for Shift and Ctrl, I hadn't perceived that as an issue, although I'm not going to say your concern isn't valid. But if an appreciable portion of the keyboard is being used for shifted Fn-functions, one needs an Fn key for both hands.
It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/“SpaceShift” brings two problems:
It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing (type fast "A and B" and you will get "AAnd B")
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating
“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.
“ShiftReturn” is the most reasonably solution in my opinion, because:
1) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
2) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
3) You will get one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have 1 additional key for your disposal.
... map a repeating space key in the fn layer as a combined keypress?Sure, you could. But to invoke autorepeat by a key combination doesn’t seem very natural / intuitive for me. By intuition we know “hold down the key and autorepeat is what follows”. What do you think.
If it is only autorepeat that you are missing with SpaceFn ...Well, doesn’t ReturnShift makes more sense, in that the key locations of the keyboard are more efficiently used? LeftShift and RightShift take up two key locations, for what, when you can have both in one location? The logic I like is: wed the most prominent key location to the most frequently used function.
... map a repeating space key in the fn layer as a combined keypress?Sure, you could. But to invoke autorepeat by a key combination doesn’t seem very natural / intuitive for me. By intuition we know “hold down the key and autorepeat is what follows”. What do you think swill.If it is only autorepeat that you are missing with SpaceFn ...Well, doesn’t ReturnShift makes more sense, in that the key locations of the keyboard are more efficiently used? LeftShift and RightShift take up two key locations, for what, when you can have both in one location?
It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing all the time: type fast "A and B" and you will get "AAnd B"
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating
“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing that much. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.
It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing (type fast "A and B" and you will get "AAnd B")
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating
“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.
“ShiftReturn” is the most reasonably solution in my opinion, because:
1) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
2) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
3) You will get one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have 1 additional key for your disposal.
If it is only autorepeat that you are missing with SpaceFn, would you be able to map a repeating space key in the fn layer as a combined keypress? Just thinking outloud here...
Not sure I like 60% due to my massive use of the arrow keys while navigating files. On one hand once used to the 60% it might actually be faster since you do not have to leave home row, on the other hand its more work when just casually scrolling.
Anyways at least Ctrl-Shift-Esc would work with this design unlike my FC600C :(
Good points, 'Dual role key' is all of trade off or compromise and which depends on your preference and typing habits. General discussion of 'Dual role key' will suit for this thread.
http://geekhack.org/index.php?topic=41685.0It made me also think, since the most common modifier is Shift, using held-down space as Shift might also be a good alternative, e.g. http://www.autohotkey.com/board/topic/57344-spacebar-as-space-and-as-shift/“SpaceShift” brings two problems:
1) shift and space oust each other in fast typing all the time: type fast "A and B" and you will get "AAnd B"
2) auto-repeating space won’t be flawlessly possible, and space is something we want to type now and then by autorepeating
“SpaceFn” is better in this regard, since space and fn don’t oust each other in fast typing that much. What remains is the problem with autorepeat. And I don’t want to live without an autorepeating space.
I saw that AHK script and have to say its implementation is too optimistic and naive for real usage of dual role key. That "AAnd B" problem is inevitable for dual role key intrisically but way better implementation can be existed. And you will be able to even optimize it accroding to your type fingering and speed. With the better and optimized dual role key you'll rarely see problems like that, but completely solution does not exists.
“ReturnShift” is the most reasonably solution in my opinion, because:It can be *VERY* dangerous though. Imagine the conversion to Shift fails, when you're doing something in CLI. It can be a disaster.
1) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
2) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
3) It’s saving resources in that you will have one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have one additional key for your disposal.
“ReturnShift” is the most reasonably solution in my opinion, because:It can be *VERY* dangerous though. Imagine the conversion to Shift fails, when you're doing something in CLI. It can be a disaster.
1) Shift is, as you said already, the most frequently used modifier, therefore it makes sense to assign this functiont to the most prominent and accessible key on the keyboard, which is the 6.25u / 7u key.
2) Return is rarely used with auto-repeat, so the lack of autorepeat should be no problem anymore, at least for my typing habits.
3) It’s saving resources in that you will have one extra key to your disposal, which is important with a 60% layout. The reason for this is, that you won’t need both RightShift key and LeftShift key anymore, since the spacebar is in reach for both hands. That means, you can assign new functions to the RightShift key and LeftShift key, and you will have one additional key for your disposal.
It can be *VERY* dangerous though. Imagine the conversion to Shift fails, when you're doing something in CLI. It can be a disaster.
Has anyone looked at adding SpaceFN to the usb_usb tmk converter?
This seems like a really attractive option because it would allow anyone to add the (supposedly) best implementation of SpaceFN to their keyboard for $22 shipped (Leonardo Arduino and USB host on eBay) and without any soldering decide whether they liked the layout. This seems like a really nice option even if some advanced keyboard options (I'm not sure exactly which) don't work with the usb_usb converter.
Unfortunately I don't know enough C to be able tell how easily the SpaceFN keymap from other directories in TMK [1] could be added to the usb_usb converter directory [2]. It appears that it might have fallen out of sync with the rest of TMK and need to be updated. Anyone familiar enough with C to see what's needed?
[1] https://github.com/tmk/tmk_keyboard/blob/master/converter/ps2_usb/keymap_spacefn.c
[2] https://github.com/tmk/tmk_keyboard/tree/master/converter/usb_usb
Thanks,
Scott
Has anyone looked at adding SpaceFN to the usb_usb tmk converter?
This seems like a really attractive option because it would allow anyone to add the (supposedly) best implementation of SpaceFN to their keyboard for $22 shipped (Leonardo Arduino and USB host on eBay) and without any soldering decide whether they liked the layout. This seems like a really nice option even if some advanced keyboard options (I'm not sure exactly which) don't work with the usb_usb converter.
Unfortunately I don't know enough C to be able tell how easily the SpaceFN keymap from other directories in TMK [1] could be added to the usb_usb converter directory [2]. It appears that it might have fallen out of sync with the rest of TMK and need to be updated. Anyone familiar enough with C to see what's needed?
[1] https://github.com/tmk/tmk_keyboard/blob/master/converter/ps2_usb/keymap_spacefn.c
[2] https://github.com/tmk/tmk_keyboard/tree/master/converter/usb_usb
Thanks,
Scott
I don't think the keymap_spacefn.c file would be the problem. This file essentially defines two data arrays that are used by the firmware to associate received scancodes to scancodes that must be output. If the TMK software, as modified to drive the USB-USB converter, is still basically the same at its core, the keymap_spacefn.c file should work as it is.
Do you know a little bit about the Leonardo Arduino and the USB host? Does the host simply piggyback on the main board? Does it have to be soldered? What is the width of the assembly? I'm trying to find out if we could easily fit this stuff inside a keyboard case, assuming we can get it to work.
I don't think the keymap_spacefn.c file would be the problem. This file essentially defines two data arrays that are used by the firmware to associate received scancodes to scancodes that must be output. If the TMK software, as modified to drive the USB-USB converter, is still basically the same at its core, the keymap_spacefn.c file should work as it is.
Do you know a little bit about the Leonardo Arduino and the USB host? Does the host simply piggyback on the main board? Does it have to be soldered? What is the width of the assembly? I'm trying to find out if we could easily fit this stuff inside a keyboard case, assuming we can get it to work.
I don't know anything about the Leonardo Arduino and USB host on a technical level. I did buy both on eBay, before looking closely at the TMK firmware, and with shipping to US included and a miniUSB->USB cable they go for $22. There is no soldering required, you basically plug them together, which took me a minute because I was really cautious but it could be done in five seconds. It is way too big to fit in a keyboard case, at least of any keyboard that I've ever seen. It is 1.125"x2.125"x2.75". I see it sitting on my desk behind my computer in a small box (when I run into a product with the right dimensions). So no good for a portable setup, but perfectly fine for testing out SpaceFN or a desktop setup. You plug your USB keyboard into the USB host and you plug the miniUSB->USB cable that came with the Leonardo into your computer. I think we could have TMK firmware precompiled with SpaceFN so placing that firmware on the Leonardo could be a few more minutes.
The USB->USB TMK firmware is limited to HID mode and from what I gather would require quite some work to overcome this. Unfortunately I don't really know what exactly the limitations of HID mode are. I gather it prevents using keys as a mouse but I'm not sure if it also means media keys don't work or what else. If it's only mouse and media keys that don't work, I think this is fine, since I see this really as being an easy and affordable way for people to see if they like SpaceFN with a good implementation of the software. If they decide they like it then they go put in the extra money and time to come up with a better solution.
As for the TMK software, I have compiled the USB->USB converter and installed it on the Leonardo, and it appeared to work fine in the few minutes I used it. The problem, from what I can tell, is that the USB->USB TMK software was written before the spacefn keymaps were created and perhaps before some refactoring of the tmk source code, so I think it needs a slight update in order for the keymap_spacefn.c to be used. Unfortunately I don't know C so I haven't been able to do this update. I'm hoping by talking about it someone else will :)
As for the TMK software, I have compiled the USB->USB converter and installed it on the Leonardo, and it appeared to work fine in the few minutes I used it. The problem, from what I can tell, is that the USB->USB TMK software was written before the spacefn keymaps were created and perhaps before some refactoring of the tmk source code, so I think it needs a slight update in order for the keymap_spacefn.c to be used. Unfortunately I don't know C so I haven't been able to do this update. I'm hoping by talking about it someone else will :)
edit: it's microUSB not miniUSB.
As for the TMK software, I have compiled the USB->USB converter and installed it on the Leonardo, and it appeared to work fine in the few minutes I used it. The problem, from what I can tell, is that the USB->USB TMK software was written before the spacefn keymaps were created and perhaps before some refactoring of the tmk source code, so I think it needs a slight update in order for the keymap_spacefn.c to be used. Unfortunately I don't know C so I haven't been able to do this update. I'm hoping by talking about it someone else will :)
edit: it's microUSB not miniUSB.
It worked? Great!
Very good indication for reviving long dead project :D
Yes, keymap of the converter is defined in old 'legacy' notation. But I think you can port SpaceFN keymap from ps2_usb converter with reading this doc. If you have questions about this post my thread.
https://github.com/tmk/tmk_keyboard/blob/master/doc/keymap.md#5-legacy-keymap
may bad queston
this is effective in ergdox/split keyboard?
[WARNING: Intentional cross-post below]
I've been watching this thread off and on since it popped up. My interest is more in custom hardware than software, and (sadly) I am not a touch-typist, so SpaceFN is not for me. But it is interesting, and I have spent much time experimenting with both sub-TKL keyboards and FN-key placement.
But one of my recent projects is the GH36 programmable matrix keypad. I have arthritis in my thumbs, so I use the keypad for ergonomic reasons as a LH half-keyboard for keyboard-and-mouse gaming. But others have seen the potential for using a pair of GH36 keypads connected to make a much lower-cost split ergonomic keyboard. (You can see an example in the GH36 thread.)
But this morning as I was reading the latest SpaceFN posts, it struck me that SpaceFN + one GH36 could result in a keyboard useable by people with only one hand. Tap the 2x-wide "spacebar" for a space; hold it to swap keyboard sides left-to-right. So...
qwert + spacebar = yuiop
12345 + spacebar = 67890
Someone with more neurology than I (or a missing hand) would have to say if the FN layer should be mirrored or not. Perhaps if a person used to touch-type and now doesn't, the remaining ring finger should be both s and l. And for someone without touch typing, the LH ring finger should be s and k (second from left) because that would make the printed keymap seem more standard.
Anyhow, just a thought. Would half of a SpaceFN keyboard be a valuable aid to someone who (e.g.) came home from military service with fewer hands?
If there is someone who would be interested in experimenting with this concept, I'd happily donate some hardware.
- Ron | samwisekoi
Sig auto-typed by my GH36 LH keypad.
may bad queston
this is effective in ergdox/split keyboard?
I don't think the keymap_spacefn.c file would be the problem. This file essentially defines two data arrays that are used by the firmware to associate received scancodes to scancodes that must be output. If the TMK software, as modified to drive the USB-USB converter, is still basically the same at its core, the keymap_spacefn.c file should work as it is.
Do you know a little bit about the Leonardo Arduino and the USB host? Does the host simply piggyback on the main board? Does it have to be soldered? What is the width of the assembly? I'm trying to find out if we could easily fit this stuff inside a keyboard case, assuming we can get it to work.
I don't know anything about the Leonardo Arduino and USB host on a technical level. I did buy both on eBay, before looking closely at the TMK firmware, and with shipping to US included and a microUSB->USB cable they go for $22. There is no soldering required, you basically plug them together, which took me a minute because I was really cautious but it could be done in five seconds. It is way too big to fit in a keyboard case, at least of any keyboard that I've ever seen. It is 1.125"x2.125"x2.75". I see it sitting on my desk behind my computer in a small box (when I run into a product with the right dimensions). So no good for a portable setup, but perfectly fine for testing out SpaceFN or a desktop setup. You plug your USB keyboard into the USB host and you plug the microUSB->USB cable that came with the Leonardo into your computer. I think we could have TMK firmware precompiled with SpaceFN so placing that firmware on the Leonardo could be a few more minutes.
The USB->USB TMK firmware is limited to HID mode and from what I gather would require quite some work to overcome this. Unfortunately I don't really know what exactly the limitations of HID mode are. I gather it prevents using keys as a mouse but I'm not sure if it also means media keys don't work or what else. If it's only mouse and media keys that don't work, I think this is fine, since I see this really as being an easy and affordable way for people to see if they like SpaceFN with a good implementation of the software. If they decide they like it then they go put in the extra money and time to come up with a better solution.
As for the TMK software, I have compiled the USB->USB converter and installed it on the Leonardo, and it appeared to work fine in the few minutes I used it. The problem, from what I can tell, is that the USB->USB TMK software was written before the spacefn keymaps were created and perhaps before some refactoring of the tmk source code, so I think it needs a slight update in order for the keymap_spacefn.c to be used. Unfortunately I don't know C so I haven't been able to do this update. I'm hoping by talking about it someone else will :)
edit: it's microUSB not miniUSB.
Good ideas never die!
http://www.keyboardco.com/keyboard/matias-half-keyboard-single-handed-keyboard.asp
http://www.keyboardco.com/keyboard/matias-half-qwerty-508-keyboard.asp
All credit goes to Matias, who actually pointed out earlier to me that he had worked on the idea of space as a dual-role modifier a long time ago.
...For example I want to add a "browser mode", that would allow you to navigate without having to hold space. It would be very comfortable when you are just reading pages in your internet browser, or in a PDF reader for example.
I have received all the required hardware (the Leonardo and the USB host card) a few days ago, and managed to compile and install the default TMK firmware.
I works. I have a keyboard attached to the USB card on one side, and the Leonardo attached to a PC. The keys are translated as expected, but I'm using the default layout provided with the firmware. It's not SpaceFN yet.
It's true that the hardware requires absolutely no knowledge of electronics. There are two cards that you need to plug into each other carefully, and you are done.
(Attachment Link)
The Leonardo Arduino (bottom) and the USB host shield rev. 2.0.1 (top).
The PC connects to the micro USB port on the bottom card.
The keyboard connects to the standard USB port on the top.
The big black power connector is not used.
Now I need to find some time to adapt the SpaceFN layout for this USB to USB converter. I hope to do better than that and add a few features to SpaceFN.
For example I want to add a "browser mode", that would allow you to navigate without having to hold space. It would be very comfortable when you are just reading pages in your internet browser, or in a PDF reader for example.
I've started experimenting with space-fn on my mac using Karabiner (previousle Keymap for macbook).
I've modified it slightly:
- I use capslock for backspace, and have now mapped Fn+Backspace to Delete
- I mapped Fn+Z/X/V to copy/cut/paste (very convenient for shift+cursor copy/paste actions)
- Mapped Fn+U/O to begin line/end line instead of mac's irritating begin/end document :)
I'm using it on a tenkyless 87% keyboard to see if I can live without cursor keys.
If anyone is interested in the private.xml please let me know and I'll post it here.
I have received all the required hardware (the Leonardo and the USB host card) a few days ago, and managed to compile and install the default TMK firmware.
I works. I have a keyboard attached to the USB card on one side, and the Leonardo attached to a PC. The keys are translated as expected, but I'm using the default layout provided with the firmware. It's not SpaceFN yet.
It's true that the hardware requires absolutely no knowledge of electronics. There are two cards that you need to plug into each other carefully, and you are done.
(Attachment Link)
The Leonardo Arduino (bottom) and the USB host shield rev. 2.0.1 (top).
The PC connects to the micro USB port on the bottom card.
The keyboard connects to the standard USB port on the top.
The big black power connector is not used.
Now I need to find some time to adapt the SpaceFN layout for this USB to USB converter. I hope to do better than that and add a few features to SpaceFN.
For example I want to add a "browser mode", that would allow you to navigate without having to hold space. It would be very comfortable when you are just reading pages in your internet browser, or in a PDF reader for example.
SpaceFN is really intresting to me, though the spacebar delay is not as much. I was trying to think of a way to get around that and this is what I've come up with.Show Image(https://dl.dropboxusercontent.com/u/510750/Misc/SplitFN.png)
It would be a custom 60% pcb with tmk compatible firmware (for hardware dual role keys like control/esc and shiftL/( or shiftR/) )
Only difference would be two switches under the spacebar. Ideally you could just buy a standard keycap set, and get an extra spacebar, which you would then cut in half, and it would just work. Though I'm not sure how to achieve that without modding the spacebar a bit. What I don't think is acceptable is using 2 3u keys upside down. (Ideally would want to maintain the normal keyset aesthetic as close as possible)
Thoughts?
True I guess my idea doesn't really have much to do with spaceFN except that spaceFN is what is what lead me to think of it. I actually haven't gotten around to using spaceFN yet because it seems the only way to do it is with software. So I've been looking for a hardware solution and nothing really caught my fancy so designing a custom board seems like the way to go. But if you're going to go through that trouble you might as well add an fn key under the unused thumb, hence my layout idea. Thanks for the layout, it's been an inspiration.
; Note: This implementation assumes an en-US QWERTY layout.
SendMode Input
#NoEnv
#SingleInstance force
options := {delay: 150, timeout: 300, doublePress: -1, swap_backtick_escape: false, mode: "ijkl"}
loop %0% {
arg := %A_Index%
argSplit := StrSplit(arg, "=")
option := argSplit[1]
value := argSplit[2]
options[option] := value
}
#Include <dual/dual>
dual := new Dual
#Include <dual/defaults>
#If options.swap_backtick_escape
*`::dual.comboKey({F22: "Escape"})
#If
#If options.mode == "ijkl"
*i::dual.comboKey({F22: "Up"})
*j::dual.comboKey({F22: "Left"})
*k::dual.comboKey({F22: "Down"})
*l::dual.comboKey({F22: "Right"})
*u::dual.comboKey({F22: "Home"})
*o::dual.comboKey({F22: "End"})
*h::dual.comboKey({F22: "PgUp"})
*n::dual.comboKey({F22: "PgDn"})
#If
#If true ; Override defaults.ahk. There will be "duplicate hotkey" errors otherwise.
*Space::
*Space UP::dual.combine("F22", A_ThisHotkey, {delay: options.delay, timeout: options.timeout, doublePress: options.doublePress})
*BackSpace::dual.comboKey({F22: "Delete"})
*b::dual.comboKey({F22: "Space"})
*1::dual.comboKey({F22: "F1"})
*2::dual.comboKey({F22: "F2"})
*3::dual.comboKey({F22: "F3"})
*4::dual.comboKey({F22: "F4"})
*5::dual.comboKey({F22: "F5"})
*6::dual.comboKey({F22: "F6"})
*7::dual.comboKey({F22: "F7"})
*8::dual.comboKey({F22: "F8"})
*9::dual.comboKey({F22: "F9"})
*0::dual.comboKey({F22: "F10"})
*-::dual.comboKey({F22: "F11"})
*=::dual.comboKey({F22: "F12"})
*p::dual.comboKey({F22: "BackSpace"})
*;::dual.comboKey({F22: "Delete"})
*e::dual.comboKey({F22: "{Shift}+{Up}"})
*d::dual.comboKey({F22: "{Shift}+{Down}"})
*s::dual.comboKey({F22: "{Shift}+{Ctrl}+{Left}"})
*f::dual.comboKey({F22: "{Shift}+{Ctrl}+{Right}"})
*q::dual.comboKey({F22: "F3"})
*a::dual.comboKey({F22: "{Shift}+{F3}"})
*g::dual.comboKey({F22: "{Shift}+{Ctrl}+{l}"})
*CapsLock::Ctrl
#If
I've tried this Karabiner and really don't like the space entering on release. Just feels... sticky. And if you type really fast it's all too easy to trigger a Fn layer key. Mapping one of the GUI keys to Fn is the way to go.
I think that'll work better, because the alt doesn't send a character to screen, making a misfire less costly. Generally any modifier will work ok in this dual-role manner.
SpaceFn is a no go for me because it introduces inaccuracy and uncertainty in to my typing, which is unacceptable. After all, we use keyboards because they're more accurate, right? Tab, esc and - also not great for similar reasons. An accidental trigger of the key itself rather than the fn version is too annoying.
I've remapped my caps lock to a dual cmd (hold) and esc (tap) key. Works well, especially if you're a vim user. I originally had issues whereby I'd send accidental escapes sometimes when I'd waver over whether I wanted to use a cmd+something shortcut, but Karabiner has a timeout, so if you hold it just a tad longer than a tap and release it's as if you just held down the cmd and released. In other words, nothing happens. I still occasionally hit an erroneous escape, but it's usually easily rectified, usually via a tab tap, or some other shortcut to focus on what I want it to.
Whenever I use Photoshop, I have to suspend SpaceFN, because Photoshop uses the spacebar extensively to navigate the image (you hold down the spacebar while dragging the image around). I often then forget to turn the script back on.
When SpaceFN is activated, you can press and hold Space-B.Definitely less convenient, since in Photoshop you often want to hold space + control, space + shift, space + alt, space + alt + ctrl (Windows, but Mac is similar).
The "B" key, in the function layer, is a space. It has been designed exactly for what you need: provide a space key that activates when you press it, not when you release it.
@spiceBar: Thank you for this creative idea. It is quite interesting. At the outset, having given credit to Edgar Matias for the concept of dual-function keys, you might wish to propose building SpaceFn keyboards using Matias Click and Matias Quiet switches.
From my own perspective, I converted over a year ago from a standard layout to the HHKB Pro 2 layout. I either use a HHKB Pro 2, or I remap standard keyboards to a Mac/HHKB Pro 2 layout. I like to have a separate Fn key, either to the right of the Right Shift or on the far right of the bottom row. I am too wedded to the standard single-purpose Spacebar to be comfortable using it also as a Fn key. However, I think if I had not made the switch to a Mac/HHKB Pro 2 layout, I might have been tempted to use your imaginative SpaceFn solution.
By the way, my second and third favorite 60% keyboards after the HHKB Pro 2 are the KBP V60 Matias Click and KBP V60 Matias Quiet keyboards, remapped using Karabiner software to a Mac/HHKB Pro 2 layout.
Whenever I use Photoshop, I have to suspend SpaceFN, because Photoshop uses the spacebar extensively to navigate the image (you hold down the spacebar while dragging the image around). I often then forget to turn the script back on.
When SpaceFN is activated, you can press and hold Space-B.
The "B" key, in the function layer, is a space. It has been designed exactly for what you need: provide a space key that activates when you press it, not when you release it.
Naturally it's less convenient than just pressing and holding space, but maybe it's less annoying than having to turn SpaceFN off.
And... doesn't Photoshop offer a way to change the key used for this function?
Almost all keyboard shortcuts in Photoshop can be changed, including the shortcuts for selecting tools, every top-of-screen menu option, and every menu option in every interface panel, and of course also user-defined actions. Unfortunately I think spacebar-for-temporary-hand-tool is among a small handful of things that can’t be changed.
I think the only real way around this problem is with control at the hardware firmware level, so that the whole computer thinks it’s getting a space character. It sounds like whatever layer of the input stack Photoshop is looking at is lower level than where SpaceFn it outputting keys, and as a result it’s not picking up space+b as space. If you can get a Teensy to stick in between your keyboard and your computer, you can run hasu’s tmk_keyboard firmware and implement space-fn there.
One of the problems with the way modern computers have their input stack implemented is that there are frequent conflicts of this sort. People running certain web browsers will sometimes end up breaking Photoshop’s spacebar feature, too.
It’s difficult if you have a USB keyboard, because your middleman hardware controller needs to handle the host side of the USB HID protocol to talk to the keyboard, and I’m not sure that code is easily available anywhere, so you might need to spend a bunch of time on USB HID protocol implementation.
If you have PS/2 (a.k.a. AT) or XT or ADB keyboards it’s pretty trivial though, since support for those protocols has already been figured out by e.g. Soarer or hasu.
It’s difficult if you have a USB keyboard, because your middleman hardware controller needs to handle the host side of the USB HID protocol to talk to the keyboard, and I’m not sure that code is easily available anywhere, so you might need to spend a bunch of time on USB HID protocol implementation.
If you have PS/2 (a.k.a. AT) or XT or ADB keyboards it’s pretty trivial though, since support for those protocols has already been figured out by e.g. Soarer or hasu.
I assume simply using a USB to PS/2 adapter isn't enough to alleviate this problem? The keyboard has to be PS/2 by default?
Do people leave the controller exposed like that, or do they always find a way to put it inside the keyboard's case? Or is there a small case for the controller itself?
Apparently the Infinity keyboard is compatible with the TMK firmware,Who says? As far as I know tmk_keyboard is AVR only (like an ATMega32 or similar) and hasu hasn’t done any ARM port. (I could be wrong though.)
I've read some forum posts about how the weird freaking out of the script I've experienced also happens with the TMK firmware for some people too. The main reason I'd want to go with a hardware solution is to avoid the freak out episodes I often experience with the AHK script.
I've been using Touchcursor (http://touchcursor.sourceforge.net/) for a few years now to emulate exactly this SpaceFN layout (for the F-row, HJKL, etc.) in several Windows machines (XP, Win 7 and 8.1). It's definitely more stable than AHK (never had a problem with Touchcursor).
I've tried a few things with the source and saw that it runs on a lower level of the OS (uses KeyboardHooks), maybe that's the reason why it's stabler than its AHK counterpart.
I have been using SpaceFN for months using the TMK firmware on a GH60, a Poker X (PS/2->USB adapter) and an HHKB (Hasu's dedicated controller) and I have never experienced any problem.
A hardware solution with TMK is very stable.
A quick update on TouchCursor:
The Photoshop spacebar temporary Hand Tool problem is also an issue, and even though TouchCursor offers the option to disable in specified programs, its implementation of that feature is extremely odd--you have to drag a bullseye cursor it provides onto the window of the program you want to disable TouchCursor on, but it doesn't work with Photoshop CS6 or ACDSee Pro 8 (I get incorrect Unicode name in random Chinese characters for both programs when I do that, and TouchCursor is not disabled in them), but it does work on the few other programs I tried the feature on. I guess for now, I'll just exit TouchCursor while working in Photoshop (similar to how I have to suspend the hotkeys of SpaceFN when using Photoshop).
A quick update on TouchCursor:
The Photoshop spacebar temporary Hand Tool problem is also an issue, and even though TouchCursor offers the option to disable in specified programs, its implementation of that feature is extremely odd--you have to drag a bullseye cursor it provides onto the window of the program you want to disable TouchCursor on, but it doesn't work with Photoshop CS6 or ACDSee Pro 8 (I get incorrect Unicode name in random Chinese characters for both programs when I do that, and TouchCursor is not disabled in them), but it does work on the few other programs I tried the feature on. I guess for now, I'll just exit TouchCursor while working in Photoshop (similar to how I have to suspend the hotkeys of SpaceFN when using Photoshop).
In other words, only a hardware implementation can solve all your problems. :)
A quick update on TouchCursor:
The Photoshop spacebar temporary Hand Tool problem is also an issue, and even though TouchCursor offers the option to disable in specified programs, its implementation of that feature is extremely odd--you have to drag a bullseye cursor it provides onto the window of the program you want to disable TouchCursor on, but it doesn't work with Photoshop CS6 or ACDSee Pro 8 (I get incorrect Unicode name in random Chinese characters for both programs when I do that, and TouchCursor is not disabled in them), but it does work on the few other programs I tried the feature on. I guess for now, I'll just exit TouchCursor while working in Photoshop (similar to how I have to suspend the hotkeys of SpaceFN when using Photoshop).
Hahahaha, probably. Having to pause/stop the software solution when using Photoshop isn't really something that bugs me too much though. The AHK freakout episodes are much more annoying, but if simply reloading the script fixes it, then that's not a big deal either. I just much prefer the flexibility and simplicity of software solutions, and prefer to avoid hardware ones if possible.
In other words, only a hardware implementation can solve all your problems. :)
I've been using Touchcursor (http://touchcursor.sourceforge.net/) for a few years now to emulate exactly this SpaceFN layout (for the F-row, HJKL, etc.) in several Windows machines (XP, Win 7 and 8.1). It's definitely more stable than AHK (never had a problem with Touchcursor).
I've tried a few things with the source and saw that it runs on a lower level of the OS (uses KeyboardHooks), maybe that's the reason why it's stabler than its AHK counterpart.
Anyone has lagging issue with TouchCursor?
noremap ; l
noremap l h
I find it more logical, I won't leave the home row and have remap space+ jkl; to arrows system wide.Hello sorry if this has been already posted I did only read the 4 first pages and posts are pretty longs.
I don't get the escape remapping as a lot of posters look like using vi/vim.
In vim control+[ gives escape, control+j gives enter and control+h gives backspace.
So I mapped these system wide as well.
For cursor movements I'm using jkl; instead of hjkl, you only have to remap l to h and ; to lCode: [Select]noremap ; l
I find it more logical, I won't leave the home row and have remap space+ jkl; to arrows system wide.
noremap l h
Hello sorry if this has been already posted I did only read the 4 first pages and posts are pretty longs.
I don't get the escape remapping as a lot of posters look like using vi/vim.
In vim control+[ gives escape, control+j gives enter and control+h gives backspace.
So I mapped these system wide as well.
For cursor movements I'm using jkl; instead of hjkl, you only have to remap l to h and ; to lCode: [Select]noremap ; l
I find it more logical, I won't leave the home row and have remap space+ jkl; to arrows system wide.
noremap l h
You are now completely off topic in this thread.
You should start a new thread about VIM if you want to discuss this further.
I've been trying this out for the last week or two and really like it. It was a little off with autohotkey, but I installed touchcursor and it seems to be working great in that.
Are there any non-custom, standard ansi layout 60% boards that can run it in hardware? I'd love a fully programmable board, but I'm not sure I'm capable of soldering the cheaper options or the expense of some type of custom korean board. Are there any standard boards that can have their bios flashed to support it?
mecano, it looks like ortholinear only offers the planck. It's a great looking design, but not exactly what I'm looking for right now.
spicebar, that's probably what I'll end up doing. It looks like hasu is working on a usb-usb converter. If he offers built versions of that for sale I'll probably end up going with it.
I found a post here https://geekhack.org/index.php?topic=69169.0
If he gets that working I think it would probably be just about perfect.
I tried running the provided ahk script and get this error:
Error at line 19.
Line Text: #Include <dual/dual>
Error: Function library not found.
The program will exit.
To anyone who's currently using AHK or thinking about trying it, I HIGHLY RECOMMEND that you instead use TouchCursor, and only use AHK if for whatever reasons TouchCursor doesn't work for you. TouchCursor is far more stable and intuitive and easy to use than AHK, and it is configured to match SpaceFN's layout very closely by default. Changing the layout is extremely easy and quick, and it pretty much never crashes or glitches (at least that's my experience, and I know others have had the same positive experience). The same cannot be said of AHK.
Just installed touch cursor, it's amazing, really excited to see if I'll be able to stick to these new changes :)
There is a hardware solution, and it has been discussed in this thread.
SpaceFN can be easily implemented as a firmware for Hasu's PS/2->USB converter.
Here is a picture of a Poker X with Hasu's converter:
(Attachment Link)
The converter translate what the keyboard sends, and sends that to the USB plug. This act as a kind of TouchCursor inside the converter, so you can plug the keyboard+converter into any computer without having to install anything on the computer.
The firmware in Hasu's converter is 100% programmable, and SpaceFN is just one of the options available.
Unfortunately, this solution works only if your keyboard is PS/2 compatible (if it can be plugged into a PS/2 port and works, plugging it directly or thru a passive PS/2 to USB adapter). But most 60% keyboards are not compatible with PS/2. The only ones I know are the Poker X (first version of the Poker), and it's not produced anymore, and the Pure (NOT the Pure Pro) which is becoming hard to find.
It is however rather easy to find a full size or TKL keyboard that is PS/2 compatible.
The other solution is the GH60, which is 100% programmable and can run Hasu's firmware, or the Infinity keyboard that was recently on MassDrop (but this drop has already ended).
The Infinity is back on Massdrop and they have a prebuilt option this time. I really want a standard ansi 60% layout for key compatibility, but that's tempting. Any issues using spacefn with the infinity?
Well remapping fn to space isn't the end of the story. You need to have taping for space abilities too.The Infinity is back on Massdrop and they have a prebuilt option this time. I really want a standard ansi 60% layout for key compatibility, but that's tempting. Any issues using spacefn with the infinity?
I don't know much the infinity but I don't see why would be a problem with SpaceFn. As long as you can remap the Fn key with your PCB you should be alright.
Well remapping fn to space isn't the end of the story. You need to have taping for space abilities too.The Infinity is back on Massdrop and they have a prebuilt option this time. I really want a standard ansi 60% layout for key compatibility, but that's tempting. Any issues using spacefn with the infinity?
I don't know much the infinity but I don't see why would be a problem with SpaceFn. As long as you can remap the Fn key with your PCB you should be alright.
I think I mistyped and meant tapping. Since the fn is the space bar, you need the ability to quickly type the space character, so the idea is to tap to type space and hold for fn, otherwise you need to do a two finger operation to type space.Well remapping fn to space isn't the end of the story. You need to have taping for space abilities too.The Infinity is back on Massdrop and they have a prebuilt option this time. I really want a standard ansi 60% layout for key compatibility, but that's tempting. Any issues using spacefn with the infinity?
I don't know much the infinity but I don't see why would be a problem with SpaceFn. As long as you can remap the Fn key with your PCB you should be alright.
What do you mean by taping?
I think I mistyped and meant tapping. Since the fn is the space bar, you need the ability to quickly type the space character, so the idea is to tap to type space and hold for fn, otherwise you need to do a two finger operation to type space.Well remapping fn to space isn't the end of the story. You need to have taping for space abilities too.The Infinity is back on Massdrop and they have a prebuilt option this time. I really want a standard ansi 60% layout for key compatibility, but that's tempting. Any issues using spacefn with the infinity?
I don't know much the infinity but I don't see why would be a problem with SpaceFn. As long as you can remap the Fn key with your PCB you should be alright.
What do you mean by taping?
It is. Quite a clever design which is why I plan to program my keyboard around it.I think I mistyped and meant tapping. Since the fn is the space bar, you need the ability to quickly type the space character, so the idea is to tap to type space and hold for fn, otherwise you need to do a two finger operation to type space.Well remapping fn to space isn't the end of the story. You need to have taping for space abilities too.The Infinity is back on Massdrop and they have a prebuilt option this time. I really want a standard ansi 60% layout for key compatibility, but that's tempting. Any issues using spacefn with the infinity?
I don't know much the infinity but I don't see why would be a problem with SpaceFn. As long as you can remap the Fn key with your PCB you should be alright.
What do you mean by taping?
I think that's the way SpaceFn is designed actually. Hold space in order to use the Fn key. However you lose the repeated space character so it has to be binded to somewhere else and I think he mapped it to the Fn + B.
Yeah that's definitely a really nice layout. It seems to be really cool I'd you touch type. I haven't tried it yet but I soon will.It is. Quite a clever design which is why I plan to program my keyboard around it.I think I mistyped and meant tapping. Since the fn is the space bar, you need the ability to quickly type the space character, so the idea is to tap to type space and hold for fn, otherwise you need to do a two finger operation to type space.Well remapping fn to space isn't the end of the story. You need to have taping for space abilities too.The Infinity is back on Massdrop and they have a prebuilt option this time. I really want a standard ansi 60% layout for key compatibility, but that's tempting. Any issues using spacefn with the infinity?
I don't know much the infinity but I don't see why would be a problem with SpaceFn. As long as you can remap the Fn key with your PCB you should be alright.
What do you mean by taping?
I think that's the way SpaceFn is designed actually. Hold space in order to use the Fn key. However you lose the repeated space character so it has to be binded to somewhere else and I think he mapped it to the Fn + B.
Tried SpaceFN with AHK on windows 8 (spacefn-win.ahk + dual lib). Alt+Tab stopped working completely. Is it a known bug? How to fix?
Upd: tried TouchCursor, problem went away, seems nicer than AHK.
Anyone getting this happen: accidentally hit a space shortcut in normal use?
Anyone getting this happen: accidentally hit a space shortcut in normal use?
I'm using a "shift-activated" version of the SpaceFn idea to allow the space bar to function as normally as possible...
A shift-activated SpaceFn requires a little more effort to activate the Fn layer and you have to rely on the the Fn layer if you want the keyboard to send Shift+Space, but I think it's a worthwhile compromise to be able to use the space bar as an Fn key and allow it to function as normally as possible. I've been using a shift-activated SpaceFn for a while now and I found it easy to learn and adjust to.
It is an interesting idea; however, it sounds overcomplicated, while the original space-Fn spirit is simplicity.
It is an interesting idea; however, it sounds overcomplicated, while the original space-Fn spirit is simplicity.
I agree that the simplicity of using the original SpaceFn to access the Fn layer can't be beat. My alternative is for anyone who likes the idea of SpaceFn but wants the space bar to activate on press and repeat on hold, and doesn't mind temporarily pressing a extra key (Shift+Space) to activate the Fn layer.
Also, I forgot to mention that LeftShift+Space and RightShift+Space can potentially be used to activate different layers which might be useful.
Is there a way to test the SpaceFN layout with only a Soarer's Converter?
Not sure if it can be programmed that way since a function key usually can't output data alone when it is tapped vs held down AFAIK. Am hoping that I'm wrong. A lot of vintage boards don't have keys on either side of the spacebar and this would be an awesome way to solve that problem.
Hey all, just chiming in that I recently started using SpaceFN and I think it makes a lot of sense. I'm using it on a 60% custom board I built using hasu's Alps PCB and nubbinator's AEKII 60% plate, both from recent group buys. In fact, I like the layout I'm using on that board so much, I switched both of my Infinities to use a ported version of the same layout. Even though the Infinities have dedicated function keys, I still end up using the spacebar most of the time.
The one addition I made was actually hasu's idea from his default config, and that was to set up the Enter key as a function modifier as well. This is a more natural reach for anyone who's used to that HHKB Fn button next to Right Shift. Anyway, after about a week typing on the AEKII 60%, I find myself almost exclusively using Enter or Space to access my function layer.
Regarding the Linux version of SpaceFn:
Ideally I would like a loadable kernel module to handle the SpaceFn functionality and I am assuming something
to do this might exist, but I have not been lucky in my googling.
The reason I would like a kernel module for this is that I want to be able to use the same layout in X11 and
in the console. I have had a look at some modules handling keyboard input but I am no Kernel hacker.
Does anyone with more knowledge than me know if this would be a reasonable task? I know there may
be differences between USB and PS2 keyboards that may complicate things, but I have no clue about the
details...
Regarding the Linux version of SpaceFn:
Ideally I would like a loadable kernel module to handle the SpaceFn functionality and I am assuming something
to do this might exist, but I have not been lucky in my googling.
The reason I would like a kernel module for this is that I want to be able to use the same layout in X11 and
in the console. I have had a look at some modules handling keyboard input but I am no Kernel hacker.
Does anyone with more knowledge than me know if this would be a reasonable task? I know there may
be differences between USB and PS2 keyboards that may complicate things, but I have no clue about the
details...
Nope sorry I can't help you on that. I'll mostly use a custom PCB to put load SpaceFn directly into the firmware so no need to install stuff on the computer.
Ah, I hadn't seen that, must check it out. I agree that is probably the best solution since
I will be sure to have the same layout across all OSs, etc.
It seems I can also define my own layers which is exactly what I would like to do, Thanks!
The USB-USB convertor is legit. Had an arduino board laying around; flashed SpaceFN onto it. Works flawlessly!
The shield is $13 and that I had to buy. Why would it be weird anyway. I've got a couple of demo boards lying around, like the xplain and a bunch of avr and pic chips. :shrug:
Just chiming in, to report on the use of the space-fn concept using TouchCursor (TC), it makes a lot of sense in my GON, actually, I have not used its FN layer for quiet some time, TC is more than enough for my needs.
One major concern for me was the occasional need I have for chords with arrow keys, for example in Excel; however, TC with the use of the space-bar and IJKL for the arrow keys is very easy to use, even with chorded commands.
I fully recommend to 60% users to give the SpaceFN concept a try; there are many options to implement it, I have found TC a very nice way to do it, and I can use it even with my laptop computer; that even though, it has dedicated arrows keys, it is easier to use the arrows with the space-bar.
Just chiming in, to report on the use of the space-fn concept using TouchCursor (TC), it makes a lot of sense in my GON, actually, I have not used its FN layer for quiet some time, TC is more than enough for my needs.
One major concern for me was the occasional need I have for chords with arrow keys, for example in Excel; however, TC with the use of the space-bar and IJKL for the arrow keys is very easy to use, even with chorded commands.
I fully recommend to 60% users to give the SpaceFN concept a try; there are many options to implement it, I have found TC a very nice way to do it, and I can use it even with my laptop computer; that even though, it has dedicated arrows keys, it is easier to use the arrows with the space-bar.
For me SpaceFn is the layout that makes the more sense when you are touch typing. I used to use a Poker II back before I learn to touch type. It felt that the fn layout was nice but since I touch type I didn't like it all. You have to move your hand out of the homing line way too much to use it so you waste too much time getting back onto it IMO. Looking forward to have my custom 60% so I can give it a try. :D
Just chiming in, to report on the use of the space-fn concept using TouchCursor (TC), it makes a lot of sense in my GON, actually, I have not used its FN layer for quiet some time, TC is more than enough for my needs.
One major concern for me was the occasional need I have for chords with arrow keys, for example in Excel; however, TC with the use of the space-bar and IJKL for the arrow keys is very easy to use, even with chorded commands.
I fully recommend to 60% users to give the SpaceFN concept a try; there are many options to implement it, I have found TC a very nice way to do it, and I can use it even with my laptop computer; that even though, it has dedicated arrows keys, it is easier to use the arrows with the space-bar.
For me SpaceFn is the layout that makes the more sense when you are touch typing. I used to use a Poker II back before I learn to touch type. It felt that the fn layout was nice but since I touch type I didn't like it all. You have to move your hand out of the homing line way too much to use it so you waste too much time getting back onto it IMO. Looking forward to have my custom 60% so I can give it a try. :D
Chorded. Think of a piano where you play a chord by striking multiple keys. Same idea, a chorded command requires multiple keystrokes.Just chiming in, to report on the use of the space-fn concept using TouchCursor (TC), it makes a lot of sense in my GON, actually, I have not used its FN layer for quiet some time, TC is more than enough for my needs.
One major concern for me was the occasional need I have for chords with arrow keys, for example in Excel; however, TC with the use of the space-bar and IJKL for the arrow keys is very easy to use, even with chorded commands.
I fully recommend to 60% users to give the SpaceFN concept a try; there are many options to implement it, I have found TC a very nice way to do it, and I can use it even with my laptop computer; that even though, it has dedicated arrows keys, it is easier to use the arrows with the space-bar.
For me SpaceFn is the layout that makes the more sense when you are touch typing. I used to use a Poker II back before I learn to touch type. It felt that the fn layout was nice but since I touch type I didn't like it all. You have to move your hand out of the homing line way too much to use it so you waste too much time getting back onto it IMO. Looking forward to have my custom 60% so I can give it a try. :D
Excuse me but what are corded commands?
Chorded. Think of a piano where you play a chord by striking multiple keys. Same idea, a chorded command requires multiple keystrokes.Just chiming in, to report on the use of the space-fn concept using TouchCursor (TC), it makes a lot of sense in my GON, actually, I have not used its FN layer for quiet some time, TC is more than enough for my needs.
One major concern for me was the occasional need I have for chords with arrow keys, for example in Excel; however, TC with the use of the space-bar and IJKL for the arrow keys is very easy to use, even with chorded commands.
I fully recommend to 60% users to give the SpaceFN concept a try; there are many options to implement it, I have found TC a very nice way to do it, and I can use it even with my laptop computer; that even though, it has dedicated arrows keys, it is easier to use the arrows with the space-bar.
For me SpaceFn is the layout that makes the more sense when you are touch typing. I used to use a Poker II back before I learn to touch type. It felt that the fn layout was nice but since I touch type I didn't like it all. You have to move your hand out of the homing line way too much to use it so you waste too much time getting back onto it IMO. Looking forward to have my custom 60% so I can give it a try. :D
Excuse me but what are corded commands?
Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
The activation time is pretty key. I'm still playing around with it but 150ms is working well for me. Occasionally I still get mixed up though.
How can you change the activation time? Is it possible to do it on custom PCB?Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
The activation time is pretty key. I'm still playing around with it but 150ms is working well for me. Occasionally I still get mixed up though.
How can you change the activation time? Is it possible to do it on custom PCB?Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
The activation time is pretty key. I'm still playing around with it but 150ms is working well for me. Occasionally I still get mixed up though.
How can you change the activation time? Is it possible to do it on custom PCB?Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
The activation time is pretty key. I'm still playing around with it but 150ms is working well for me. Occasionally I still get mixed up though.
Yes you would need to use a controller or converter running firmware that allowed you to modify those settings. Anything that supports TMK firmware would do it.
No, it's a software thing. But it requires a board that runs TMK firmware. You should know if you have this.How can you change the activation time? Is it possible to do it on custom PCB?Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
The activation time is pretty key. I'm still playing around with it but 150ms is working well for me. Occasionally I still get mixed up though.
Yes you would need to use a controller or converter running firmware that allowed you to modify those settings. Anything that supports TMK firmware would do it.
Do you mean I would need to add components to my PCB? How do I know if it isn't already stock on my PCB?
No, it's a software thing. But it requires a board that runs TMK firmware. You should know if you have this.How can you change the activation time? Is it possible to do it on custom PCB?Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
The activation time is pretty key. I'm still playing around with it but 150ms is working well for me. Occasionally I still get mixed up though.
Yes you would need to use a controller or converter running firmware that allowed you to modify those settings. Anything that supports TMK firmware would do it.
Do you mean I would need to add components to my PCB? How do I know if it isn't already stock on my PCB?
I don't know what kind of chip the b. PCBs use, but if it's an AVR chip you should be able to flash it with TMK.No, it's a software thing. But it requires a board that runs TMK firmware. You should know if you have this.How can you change the activation time? Is it possible to do it on custom PCB?Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
The activation time is pretty key. I'm still playing around with it but 150ms is working well for me. Occasionally I still get mixed up though.
Yes you would need to use a controller or converter running firmware that allowed you to modify those settings. Anything that supports TMK firmware would do it.
Do you mean I would need to add components to my PCB? How do I know if it isn't already stock on my PCB?
Hum alright. I have a b.face PCB from winkeyless store. I don't know if it has TMK firmware on it. I guess that if it doesn't have it I can just flash it, isn't it?
I don't know what kind of chip the b. PCBs use, but if it's an AVR chip you should be able to flash it with TMK.No, it's a software thing. But it requires a board that runs TMK firmware. You should know if you have this.How can you change the activation time? Is it possible to do it on custom PCB?Doesn't anybody have a problem with accidentally activating the fn layer when using this? I added it to my adb-usb config and couldn't type for crap heh...
The activation time is pretty key. I'm still playing around with it but 150ms is working well for me. Occasionally I still get mixed up though.
Yes you would need to use a controller or converter running firmware that allowed you to modify those settings. Anything that supports TMK firmware would do it.
Do you mean I would need to add components to my PCB? How do I know if it isn't already stock on my PCB?
Hum alright. I have a b.face PCB from winkeyless store. I don't know if it has TMK firmware on it. I guess that if it doesn't have it I can just flash it, isn't it?
Giving this a try now. As a long-term Vim user, the HJKL stuff is a no-brainer.
Outside of Vim, though, I am finding it hard to type combos like Shift-Command-Right (ie. select to end of line), which ends up being Shift-Command-Space-L, which is a bit awkward. Perhaps it will start to feel a bit better with practice.
(Yes, I know I could/should use "End" instead, but there's a force of habit here...)
Might want to take a look at the thread below for the b.face. I believe it covers all the face PCBs. Believe its an AVR too. I haven't read through the entire thread yet, but I believe it to have SpaceFn already built in, hence why its on my list of PCBs to look at for one of my future projects.
https://geekhack.org/index.php?topic=58945.0 (https://geekhack.org/index.php?topic=58945.0)
# Yes, this is a FN layer press:
space -------------------------------
other --------------
# Nope, this is just normal rollover, typical when you type fast
space ------------------
other ----------------------
Send 3dpoly{ENTER}
Hi, thank you for providing a quick and easy AHK script for trying out SpaceFn. I've been playing around with SpaceFN for a few days and its pretty cool. I'm trying it out on a TKL at the moment, but I think it has convinced me to finally try out a 60%.
I'm a CAD guy, so I'm always looking for ways to add as much functionality to the left side of my keyboard as possible so I can leave my right hand on my mouse until I have to actually type an email or something. Having the arrows at WASD saves me from having to reach over to the right side of the keyboard with my left hand.
Something I'm curious of though, and I hope this isn't too much of a noob question. Is it possible to use SpaceFn (currently using the AHK version) to send a string of text (CAD command)?
For example: Space+Q would send something likeCode: [Select]Send 3dpoly{ENTER}
Or is this limited to only keyboard functions? Thanks!
*w::dual.comboKey({F22: "Up"})
*a::dual.comboKey({F22: "Left"})
*s::dual.comboKey({F22: "Down"})
*d::dual.comboKey({F22: "Right"})
*q::dual.comboKey({F22: "Send hello world{enter}"})
Thanks for that link, there are some neat ideas in there. I apologize though, I think my first post was a little vague. My problem isn't really specific to CAD/AHK coding, it's combining my existing macros into the SpaceFn script.
For example, I tried this in the SpaceFn script to try and have Space+Q send "hello world" then the enter key.Code: [Select]*w::dual.comboKey({F22: "Up"})
*a::dual.comboKey({F22: "Left"})
*s::dual.comboKey({F22: "Down"})
*d::dual.comboKey({F22: "Right"})
*q::dual.comboKey({F22: "Send hello world{enter}"})
The code above loads without any errors, Space+WASD all works, but Space+Q does nothing. I'm obviously missing something. How would I correct the code to send "hello world" when pressing Space+Q? Once I understand this small step I can paste in some of my existing macros.
Thanks!
I'd add a couple items from the KBParadise V60: 1) Put in a DIP switch to change the control key to fn; 2) Add an arrow cluster to WASD and either move or eliminate the Mac-only media controls.
I've set up Tab as a tap key for layer switching. Tab by itself makes a tab character, Tab+Q switches to QWERTY, Tab+D for Dvorak, and Tab+G for my gamer layout, which is just QWERTY with spacefn and winkeys disabled. Works pretty well.I'd add a couple items from the KBParadise V60: 1) Put in a DIP switch to change the control key to fn; 2) Add an arrow cluster to WASD and either move or eliminate the Mac-only media controls.
I think using space as fn while holding, its one of most clever ergonomic thing i ever ever experienced on 60% which don't have dedicated arrows cluster
The only issue i have its about gaming but i ve figured it out:
- In TMK layout, i ve added another layer that has normal spacebar through a toggle FN key
- I ve modified also the arrow clusters as WASD, its only subjective though
I actually included all sort of possibility to use secondary functions keys
- holding space as FN
- toggling a FN key
It may sound a bit complicated and complexe as own setup but in practicing, it works like a charm
I've set up Tab as a tap key for layer switching. Tab by itself makes a tab character, Tab+Q switches to QWERTY, Tab+D for Dvorak, and Tab+G for my gamer layout, which is just QWERTY with spacefn and winkeys disabled. Works pretty well.I'd add a couple items from the KBParadise V60: 1) Put in a DIP switch to change the control key to fn; 2) Add an arrow cluster to WASD and either move or eliminate the Mac-only media controls.
I think using space as fn while holding, its one of most clever ergonomic thing i ever ever experienced on 60% which don't have dedicated arrows cluster
The only issue i have its about gaming but i ve figured it out:
- In TMK layout, i ve added another layer that has normal spacebar through a toggle FN key
- I ve modified also the arrow clusters as WASD, its only subjective though
I actually included all sort of possibility to use secondary functions keys
- holding space as FN
- toggling a FN key
It may sound a bit complicated and complexe as own setup but in practicing, it works like a charm
Steal away, that's why I shared it!I've set up Tab as a tap key for layer switching. Tab by itself makes a tab character, Tab+Q switches to QWERTY, Tab+D for Dvorak, and Tab+G for my gamer layout, which is just QWERTY with spacefn and winkeys disabled. Works pretty well.I'd add a couple items from the KBParadise V60: 1) Put in a DIP switch to change the control key to fn; 2) Add an arrow cluster to WASD and either move or eliminate the Mac-only media controls.
I think using space as fn while holding, its one of most clever ergonomic thing i ever ever experienced on 60% which don't have dedicated arrows cluster
The only issue i have its about gaming but i ve figured it out:
- In TMK layout, i ve added another layer that has normal spacebar through a toggle FN key
- I ve modified also the arrow clusters as WASD, its only subjective though
I actually included all sort of possibility to use secondary functions keys
- holding space as FN
- toggling a FN key
It may sound a bit complicated and complexe as own setup but in practicing, it works like a charm
Oooh, I like this idea. I'm stealing some of it. :thumb:
I really want to love spaceFN but I just cant get past accidentally activating the FN. I changed the timing to 300ms in TMK and it still was frustrating to use. Any longer than 300ms was too slow and is annoying to use the default layer and I don't even type that fast right now. Is there something else I should try before giving up completely?
I really want to love spaceFN but I just cant get past accidentally activating the FN. I changed the timing to 300ms in TMK and it still was frustrating to use. Any longer than 300ms was too slow and is annoying to use the default layer and I don't even type that fast right now. Is there something else I should try before giving up completely?
Work on speed. If you're accidentally activating the SpaceFn layer, you're spending too long pressing down on the keys.
I'm not trying to say "anyone who hates SpaceFn is wrong" or anything like that, but it seems to me that if you're spending 200ms on each key then there's something majorly wrong with your typing technique (IMHO).
Is Space-FN the best? Well, there is always tolerance for less efficient methods.Do you have other layout to suggest? Or are you just trolling pointlessly?
Is Space-FN the best? Well, there is always tolerance for less efficient methods.Do you have other layout to suggest? Or are you just trolling pointlessly?
Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji12.png)
Oh ok. By less efficient do you mean having Fn on another key or less efficient SpaceFn layout?Is Space-FN the best? Well, there is always tolerance for less efficient methods.Do you have other layout to suggest? Or are you just trolling pointlessly?
Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji12.png)
What I meant is that Sp+FN is the best; however, some still use less efficient methods. But yeah, I am trolling sort of pointlessly.
Oh ok. By less efficient do you mean having Fn on another key or less efficient SpaceFn layout?Is Space-FN the best? Well, there is always tolerance for less efficient methods.Do you have other layout to suggest? Or are you just trolling pointlessly?
Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji12.png)
What I meant is that Sp+FN is the best; however, some still use less efficient methods. But yeah, I am trolling sort of pointlessly.Show Image(https://s3.amazonaws.com/tapatalk-emoji/emoji14.png)
Once I started to touch type it stroke me that having Fn on space was the best position. All the other positions force you to move your hand away from the home row.
Thanks for that link, there are some neat ideas in there. I apologize though, I think my first post was a little vague. My problem isn't really specific to CAD/AHK coding, it's combining my existing macros into the SpaceFn script.
For example, I tried this in the SpaceFn script to try and have Space+Q send "hello world" then the enter key.Code: [Select]*w::dual.comboKey({F22: "Up"})
*a::dual.comboKey({F22: "Left"})
*s::dual.comboKey({F22: "Down"})
*d::dual.comboKey({F22: "Right"})
*q::dual.comboKey({F22: "Send hello world{enter}"})
The code above loads without any errors, Space+WASD all works, but Space+Q does nothing. I'm obviously missing something. How would I correct the code to send "hello world" when pressing Space+Q? Once I understand this small step I can paste in some of my existing macros.
Thanks!
You'll need to use the Dual API (https://github.com/lydell/dual#api). This seems like it should work:
+q::dual.Send("hello, world")
If you are in windows you can use Touch-Cursor for your FN commands; then, you can use AHK script for macros, without having them clashing.
Thanks for pointing me back to the Dual API, I've read through that a few times and I'm still unable to do what I want. The code you suggested above only binds the Q key. Wouldn't I still need dual.comboKey to leave Q alone until I press space+Q? So, some variation of dual.comboKey + dual.send? I feel like I'm usually pretty good at figuring things out with API documentation, but this is a little confusing to me. Is anyone using SpaceFn to send a string of text?
q::
dual.combo()
if (GetKeyState("F22")) {
dual.Send("hello, world")
} else {
Hotkey, q, Off
SendInput q
Hotkey, q, On
}
return
Here's a working solution:Code: [Select]q::
dual.combo()
if (GetKeyState("F22")) {
dual.Send("hello, world")
} else {
Hotkey, q, Off
SendInput q
Hotkey, q, On
}
return
I agree that the Dual API documentation is confusing. A partial solution can be found under this section (https://github.com/lydell/dual#the--combiner). I just added a couple of calls to the Hotkey function to prevent the hotkey from being recursive.
*q::
dual.combo(F22)
if (GetKeyState("F22")) {
dual.Send("hello world{ENTER}" )
} else {
SendInput q
}
return
Thanks joc! I saw that example with the message box but I couldn't figure out how to format it correctly. This is what ended up working for me:Code: [Select]*q::
dual.combo(F22)
if (GetKeyState("F22")) {
dual.Send("hello world{ENTER}" )
} else {
SendInput q
}
return
I was getting a "Nonexistent Hotkey" error when I included the extra Hotkey lines and press Q without space. But this seems to work, so far.
I really like the idea of using the space bar as the Fn key, its position is really comfortable and intuitive. The next best thing would maybe be a second space bar as a dedicated Fn switch below the space bar, or like the button on the Smart68 keyboard. Eventually id like to get something custom like that but in the meantime this is pretty fun to play around with on the software side.
Thank you for your help!
; Note: This implementation assumes an en-US QWERTY layout.
SendMode Input
#NoEnv
#SingleInstance force
options := {delay: 150, timeout: 300, doublePress: -1, swap_backtick_escape: false, mode: "ijkl"}
loop %0% {
arg := %A_Index%
argSplit := StrSplit(arg, "=")
option := argSplit[1]
value := argSplit[2]
options[option] := value
}
#Include <dual/dual>
dual := new Dual
#Include <dual/defaults>
#If options.swap_backtick_escape
*`::dual.comboKey({F22: "Escape"})
#If
#If options.mode == "ijkl"
*i::dual.comboKey({F22: "Up"})
*j::dual.comboKey({F22: "Left"})
*k::dual.comboKey({F22: "Down"})
*l::dual.comboKey({F22: "Right"})
*u::dual.comboKey({F22: "Home"})
*o::dual.comboKey({F22: "End"})
*h::dual.comboKey({F22: "PgUp"})
*n::dual.comboKey({F22: "PgDn"})
*m::dual.comboKey({F22: "``"})
*,::dual.comboKey({F22: "~"})
#If
#If options.mode == "ijkl2"
*i::dual.comboKey({F22: "Up"})
*j::dual.comboKey({F22: "Left"})
*k::dual.comboKey({F22: "Down"})
*l::dual.comboKey({F22: "Right"})
*,::dual.comboKey({F22: "Down"})
*u::dual.comboKey({F22: "Home"})
*m::dual.comboKey({F22: "End"})
*o::dual.comboKey({F22: "PgUp"})
*.::dual.comboKey({F22: "PgDn"})
#If
#If options.mode == "hjkl"
*h::dual.comboKey({F22: "Left"})
*j::dual.comboKey({F22: "Down"})
*k::dual.comboKey({F22: "Up"})
*l::dual.comboKey({F22: "Right"})
*y::dual.comboKey({F22: "Home"})
*u::dual.comboKey({F22: "PgUp"})
*i::dual.comboKey({F22: "PgDn"})
*o::dual.comboKey({F22: "End"})
*n::dual.comboKey({F22: "Home"})
*m::dual.comboKey({F22: "PgUp"})
*,::dual.comboKey({F22: "PgDn"})
*.::dual.comboKey({F22: "End"})
#If
#If options.mode == "wasd"
*w::dual.comboKey({F22: "Up"})
*a::dual.comboKey({F22: "Left"})
*s::dual.comboKey({F22: "Down"})
*d::dual.comboKey({F22: "Right"})
*q::dual.comboKey({F22: "Home"})
*e::dual.comboKey({F22: "End"})
*f::dual.comboKey({F22: "PgUp"})
*c::dual.comboKey({F22: "PgDn"})
#If
#If true ; Override defaults.ahk. There will be "duplicate hotkey" errors otherwise.
*Space::
*Space UP::dual.combine("F22", A_ThisHotkey, {delay: options.delay, timeout: options.timeout, doublePress: options.doublePress})
*BackSpace::dual.comboKey({F22: "Delete"})
*\::dual.comboKey({F22: "Insert"})
*b::dual.comboKey({F22: "Space"})
*1::dual.comboKey({F22: "F1"})
*2::dual.comboKey({F22: "F2"})
*3::dual.comboKey({F22: "F3"})
*4::dual.comboKey({F22: "F4"})
*5::dual.comboKey({F22: "F5"})
*6::dual.comboKey({F22: "F6"})
*7::dual.comboKey({F22: "F7"})
*8::dual.comboKey({F22: "F8"})
*9::dual.comboKey({F22: "F9"})
*0::dual.comboKey({F22: "F10"})
*-::dual.comboKey({F22: "F11"})
*=::dual.comboKey({F22: "F12"})
*p::dual.comboKey({F22: "PrintScreen"})
*[::dual.comboKey({F22: "ScrollLock"})
*]::dual.comboKey({F22: "Pause"})
*e::dual.comboKey({F22: "Escape"})
*`::dual.comboKey("Escape", {F22: "``"})
#If
; This works fine because it's not within an #If block.
q::
dual.combo()
if (GetKeyState("F22")) {
dual.Send("hello, world")
} else {
Hotkey, q, Off
SendInput q
Hotkey, q, On
}
return
; This results in an error => "Error: Nonexistent hotkey variant (IfWin)."
#If true
q::
dual.combo()
if (GetKeyState("F22")) {
dual.Send("hello, world")
} else {
Hotkey, q, Off
SendInput q
Hotkey, q, On
}
return
#If
You're welcome. I forgot to mention that error. My solution only works when it's outside an #If block for some reason. Here's the default spacefn-win.ahk file with a working and nonworking solution at the bottom:Code: [Select]; Note: This implementation assumes an en-US QWERTY layout.
SendMode Input
#NoEnv
#SingleInstance force
options := {delay: 150, timeout: 300, doublePress: -1, swap_backtick_escape: false, mode: "ijkl"}
loop %0% {
arg := %A_Index%
argSplit := StrSplit(arg, "=")
option := argSplit[1]
value := argSplit[2]
options[option] := value
}
#Include <dual/dual>
dual := new Dual
#Include <dual/defaults>
#If options.swap_backtick_escape
*`::dual.comboKey({F22: "Escape"})
#If
#If options.mode == "ijkl"
*i::dual.comboKey({F22: "Up"})
*j::dual.comboKey({F22: "Left"})
*k::dual.comboKey({F22: "Down"})
*l::dual.comboKey({F22: "Right"})
*u::dual.comboKey({F22: "Home"})
*o::dual.comboKey({F22: "End"})
*h::dual.comboKey({F22: "PgUp"})
*n::dual.comboKey({F22: "PgDn"})
*m::dual.comboKey({F22: "``"})
*,::dual.comboKey({F22: "~"})
#If
#If options.mode == "ijkl2"
*i::dual.comboKey({F22: "Up"})
*j::dual.comboKey({F22: "Left"})
*k::dual.comboKey({F22: "Down"})
*l::dual.comboKey({F22: "Right"})
*,::dual.comboKey({F22: "Down"})
*u::dual.comboKey({F22: "Home"})
*m::dual.comboKey({F22: "End"})
*o::dual.comboKey({F22: "PgUp"})
*.::dual.comboKey({F22: "PgDn"})
#If
#If options.mode == "hjkl"
*h::dual.comboKey({F22: "Left"})
*j::dual.comboKey({F22: "Down"})
*k::dual.comboKey({F22: "Up"})
*l::dual.comboKey({F22: "Right"})
*y::dual.comboKey({F22: "Home"})
*u::dual.comboKey({F22: "PgUp"})
*i::dual.comboKey({F22: "PgDn"})
*o::dual.comboKey({F22: "End"})
*n::dual.comboKey({F22: "Home"})
*m::dual.comboKey({F22: "PgUp"})
*,::dual.comboKey({F22: "PgDn"})
*.::dual.comboKey({F22: "End"})
#If
#If options.mode == "wasd"
*w::dual.comboKey({F22: "Up"})
*a::dual.comboKey({F22: "Left"})
*s::dual.comboKey({F22: "Down"})
*d::dual.comboKey({F22: "Right"})
*q::dual.comboKey({F22: "Home"})
*e::dual.comboKey({F22: "End"})
*f::dual.comboKey({F22: "PgUp"})
*c::dual.comboKey({F22: "PgDn"})
#If
#If true ; Override defaults.ahk. There will be "duplicate hotkey" errors otherwise.
*Space::
*Space UP::dual.combine("F22", A_ThisHotkey, {delay: options.delay, timeout: options.timeout, doublePress: options.doublePress})
*BackSpace::dual.comboKey({F22: "Delete"})
*\::dual.comboKey({F22: "Insert"})
*b::dual.comboKey({F22: "Space"})
*1::dual.comboKey({F22: "F1"})
*2::dual.comboKey({F22: "F2"})
*3::dual.comboKey({F22: "F3"})
*4::dual.comboKey({F22: "F4"})
*5::dual.comboKey({F22: "F5"})
*6::dual.comboKey({F22: "F6"})
*7::dual.comboKey({F22: "F7"})
*8::dual.comboKey({F22: "F8"})
*9::dual.comboKey({F22: "F9"})
*0::dual.comboKey({F22: "F10"})
*-::dual.comboKey({F22: "F11"})
*=::dual.comboKey({F22: "F12"})
*p::dual.comboKey({F22: "PrintScreen"})
*[::dual.comboKey({F22: "ScrollLock"})
*]::dual.comboKey({F22: "Pause"})
*e::dual.comboKey({F22: "Escape"})
*`::dual.comboKey("Escape", {F22: "``"})
#If
; This works fine because it's not within an #If block.
q::
dual.combo()
if (GetKeyState("F22")) {
dual.Send("hello, world")
} else {
Hotkey, q, Off
SendInput q
Hotkey, q, On
}
return
; This results in an error => "Error: Nonexistent hotkey variant (IfWin)."
#If true
q::
dual.combo()
if (GetKeyState("F22")) {
dual.Send("hello, world")
} else {
Hotkey, q, Off
SendInput q
Hotkey, q, On
}
return
#If
I found that using *q is less responsive than temporarily disabling the hotkey (Hotkey, q, Off ... Hotkey, q, On); by "less responsive" I mean that you need to hold down the space bar for a longer amount of time before it's recognized as SpaceFn.
FN ----------------------
KEY ------------------
x y z
Using some user-defined constants DX, DY, and DZ, how about:if (x > DX || y > DY) ismod = true;
if (x + y > DZ && z == 0) cancel = true;
Can someone explains the advantages and drawbacks of using AHK scripts against Touch-Coursor?
Can someone explains the advantages and drawbacks of using AHK scripts against Touch-Coursor?
No one?
Can someone explains the advantages and drawbacks of using AHK scripts against Touch-Coursor?
No one?
Every since I started using TouchCursor, I have stopped using AHK completely. At first I still used AHK to swap Caps Lock and Control on some keyboards, but I realized that my muscle memory is so ingrained to the CTRL+Hotkey combos I've been using for almost two decades that I just can't make the switch to using the Caps Lock key as Control. Since then, I have stopped using AHK completely and only use TouchCursor. TouchCursor is far more stable/reliable and intuitive/easy to use, with no drawbacks. The only advantage AHK offers is if you need a specific function that TouchCursor doesn't offer. If TouchCursor already does everything you need, there's absolutely no need to use AHK at all--it only adds instability and cause weird keyboard input glitches that are really hard to troubleshoot and correct (for me, I'd have to close AHK and repeated press the Shift key).
Seriously, TouchCursor is freaking awesome.
how can I set arrow keys to Space+A/W/S/D??
(W up,A right...)
dont get it(changed every variable i could find)
please sent it to me/a zip archive
thanks
I've been using SpaceFN with TouchCursor and it's been working really well. Having a pseudo-layer control right under my thumbs is just fantastic. One problem I have with TouchCursor is that it is only capable of keeping one setup/profile. This usually wouldn't be a problem, but I'm in the process of learning Colemark and that means anything I setup with TouchCursor in QWERTY wouldn't work when I'm typing in Colemark (and vice versa). So I bought a Frosty Flake to use with my QFR that's been collecting dust hoping it'll be solution to my problem (QWERTY in one layer, Colemark in another layer, with access to the SpaceFN layer from both). I setup the whole thing using EasyAVR and everything was working swimmingly - until I started typing. The rollover problem with this setup was such that I was consistently missing space and/or activating SpaceFN layer while typing. This surprised me since I had no issue with rollover with TouchCursor. So for now, back to TouchCursor for me and QFR is also back collecting dust again.
And I havne’t even tackled the work Mac yet.
You may want to give TMK a try instead. I just recently got a Frosty Flake for my QFR, but haven't installed it yet so I don't know for sure it would solve your issue. I use SpaceFN on a couple other keyboards with TMK and it works great. I like it even better than TouchCursor. I haven't used EasyAVR before, so I can't compare them, but my guess is TMK will give you what you are looking for. Maybe I'll have some free time this weekend and give it a go on my QFR.
Thanks for the tip. I'll see how far I'll get with TMK since I have absolutely no coding background.
After much trial and error, I finally have the TMK working on my QFR w/ Frosty Flake. The whole process got a lot easier once I realized that someone else had done most of the work for me (https://github.com/bgould/costar_tmk_keyboard). SpaceFN is now working beautifully with no rollover issues. I still need to fix one of the keyswitch LED being constantly on, but that is a TMK issue not SpaceFN.
Well, space FN is a concept, not a software; thus, how could it be the culprit of your keyboard malfunctioning. In the other hand, I wonder why you want your keyboard to have the space FN flashed, while a simple software solution could do the trick, and work along any laptop or PC you might have with for example TouchCursor.I never said anything about SpaceFN causing my keyboard to malfunction. As stated earlier, I'm in the process of (slowly) learning Colemark and that means anything I had setup with TouchCursor in QWERTY wouldn't work when I'm typing in Colemark since TouchCursor can't keep multiple setups. This is why I wanted to use Frosty Flake - QWERTY in one layer, Colemark in another layer, with access to the SpaceFN layer from both. I initially used EasyAVR Keymapper, but that resulted in rollover issues that I couldn't solve via settings available on EasyAVR Keymapper. TMK allows me to use SpaceFN in both Colemark and QWERTY with no rollover issues. If I didn't want SpaceFN working on both Colemark and QWERTY, I'd been perfectly happy with just using TouchCursor without going through the trouble of using TMK.
Well, space FN is a concept, not a software; thus, how could it be the culprit of your keyboard malfunctioning. In the other hand, I wonder why you want your keyboard to have the space FN flashed, while a simple software solution could do the trick, and work along any laptop or PC you might have with for example TouchCursor.I never said anything about SpaceFN causing my keyboard to malfunction. As stated earlier, I'm in the process of (slowly) learning Colemark and that means anything I had setup with TouchCursor in QWERTY wouldn't work when I'm typing in Colemark since TouchCursor can't keep multiple setups. This is why I wanted to use Frosty Flake - QWERTY in one layer, Colemark in another layer, with access to the SpaceFN layer from both. I initially used EasyAVR Keymapper, but that resulted in rollover issues that I couldn't solve via settings available on EasyAVR Keymapper. TMK allows me to use SpaceFN in both Colemark and QWERTY with no rollover issues. If I didn't want SpaceFN working on both Colemark and QWERTY, I'd been perfectly happy with just using TouchCursor without going through the trouble of using TMK.
Also, now that I've managed to get TMK working, this keyboard will eventually be used at work where I can't rely on software solutions.
Solution which works also on console in addition to Xorg would be preferable.Yeah, I think it's going to prove far easier to do it in X than the console, but doing it in the console would be preferable (since it logically would work in X, too).
On second though, the impending demise of X for Wayland/Mir makes a console port really the only (sane) way to go. :/Solution which works also on console in addition to Xorg would be preferable.Yeah, I think it's going to prove far easier to do it in X than the console, but doing it in the console would be preferable (since it logically would work in X, too).
#include "s60-x.h"
const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
LEGACY_KEYMAP(
ESC, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, MINS, EQL, NO, BSPC, \
TAB, Q, W, E, R, T, Y, U, I, O, P, LBRC, RBRC, DELETE, \
CAPS, A, S, D, F, G, H, J, K, L, SCLN, QUOT, NO, ENT, \
LSFT, NO, Z, X, C, V, B, N, M, COMM, DOT, SLSH, UP, FN2, \
LCTL, LGUI, LALT, FN0, MYCM, FN1, LEFT, DOWN, RIGHT),
LEGACY_KEYMAP(
GRV, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, TRNS, INS, \
HOME, TRNS, UP, ESC, TRNS, TRNS, TRNS, TRNS, TRNS, END, INS, HOME, PGUP, BSLASH , \
END, LEFT, DOWN, RIGHT, TRNS, TRNS, TRNS, TRNS, TRNS, TRNS, DELETE, END, PGDN, TRNS, \
PGUP, TRNS, TRNS, TRNS, TRNS, SPC, TRNS, TRNS, TRNS, TRNS, VOLUP, VOLDOWN, MUTE, PGUP, FN2, \
PGDN, PSCR, LALT, TRNS, CALC, FN1, HOME, PGDN, END),
};
const uint16_t PROGMEM fn_actions[] = {
- = ACTION_LAYER_TAP_KEY(1, KC_SPACE),
[1] = ACTION_MODS_KEY(MOD_LSFT, KC_GRV), // tilde
};
LEGACY_KEYMAP(
EQL, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, MINS, EQL, NO, BSPC, \
PPLS , 4, 5, 6, TRNS, TRNS, TRNS, 4, 5, 6, , LBRC, RBRC, DELETE, \
PMNS , 7, 8, 9, 0, TRNS, TRNS,TRNS, 1, 2, 3, SCLN, QUOT, NO, ENT, \
PAST ,NO, 0, PDOT , NO,NO, NO, NO, 0, COMM, DOT, RSFT, UP, FN2, \
PSLS ,LGUI,ENT, SPC, CALC, FN1, LEFT, DOWN, RIGHT)
It's nice that arrows for navigation are right on the home key row. However, holding down the Fn key with the pinky is just second nature. To me this seems awkward, but it may not be once you have ridden the learning curve.
For some reason I only use my right thumb on the space bar, I just don't use my left. In doing so you with the right thumb you are going to lose some dexterity in the other fingers which makes it awkward.
So, I'm confused, what are the hardware limitations to this, and how do I implement this into TMK? Can I use a Teensy 2.0?
So, I'm confused, what are the hardware limitations to this, and how do I implement this into TMK? Can I use a Teensy 2.0?
Here's my implementation for Karabiner-Elements (for when I'm on my MBP's keyboard: https://github.com/U47/KE-complex_modifications/commit/55107588edd5e4017abb3a80524d379e5c707fa2
Pull req for inclusion directly in Karabiner-Elements: https://github.com/pqrs-org/KE-complex_modifications/pull/97
Still some timing issues with space (which I think are solved in TMK with oneshot.
Just just freaking fn on capslock. who needs capslock? OH, and if you do, fn shift
Here's my implementation for Karabiner-Elements (for when I'm on my MBP's keyboard: https://github.com/U47/KE-complex_modifications/commit/55107588edd5e4017abb3a80524d379e5c707fa2
Pull req for inclusion directly in Karabiner-Elements: https://github.com/pqrs-org/KE-complex_modifications/pull/97
Still some timing issues with space (which I think are solved in TMK with oneshot.
I have Karabiner, how do I add this to it to get spacefn? :)
Are there a working Linux solution? I have tried Xcape, but I don't think it's good enough. I can't write faster than 30-40 WPM with Xcape.I made a little XTEST/RECORD-based implementation a few years ago. I never really used it, but I still have the source code around, if anyone wants to have it.
Are there a working Linux solution? I have tried Xcape, but I don't think it's good enough. I can't write faster than 30-40 WPM with Xcape.
Hi sorry I'm completely new at this so forgive if someone asked this already. Here is my novice question: How do you increase the time to activate SpaceFN? I figured it out a long time ago, but recently updated my os. The problem I have is that when I type fast it activates SpaceFN. I would like the time to activate SpaceFN when pressing the Space Bar to be a bit longer. I am using the new Karabiner-Elements. Thanks in advance.
After seeing this thread a couple of weeks ago, I decided to try the SpaceFn concept on my boards that support TMK and QMK after reading about "tap keys" that are built into those Firmwares.
So I first tried it on my Redscarf board, and went to the TMK programming site and set the spacebar as a dual-roll function key. When pressed, it acts as a normal spacebar, but when held, it becomes my function key. It works great! It makes it super easy to dab F5 to refresh a web page or or use the Function keys when gaming without having to fumble around looking for that dedicated Fn key - just hold the space bar, and they are instantly accessible without moving your hands.
So then I grabbed one of my other boards that uses QMK and went to kbfirmware.com, and assigned the space bar to L(T) [Layer Toggle], assigned the toggled layer to layer 1 and the keypress to space. The code looks like this - LT(1,SPACE). This also worked perfectly.
AFAIK, the default time limit for tap vs hold is 200ms on these firmwares. So as long as your tap/hold time is shorter than that, you'll always get a space inserted when you are typing. For me, it's been at least 99% accurate on my taps.
In TMK, I also bound layer 1 to backlight ON, so that whenever layer 1 is active, the whole keyboard lights up at full brightness (I normally have backlight off or on low). What this does is give me a visual cue that the momentary layer switch is active. So when you press that space bar, after a moment, the kb lights up and informs you it's ready for your secondary input.
This is really a brilliant way to use an Fn key, and now I'm annoyed when I used a keyboard that doesn't have this option available :-P
99% is a little bit too low considering that it's my most used key
While working on my Linux implementation (see a few posts up), I tried a timer-based approach like what you're describing. It didn't work well for me: I frequently ended up with space-and-the-a-letter when I intended to press an arrow or navigation key real quick. I had to switch to a buffer-based approach.
While working on my Linux implementation (see a few posts up), I tried a timer-based approach like what you're describing. It didn't work well for me: I frequently ended up with space-and-the-a-letter when I intended to press an arrow or navigation key real quick. I had to switch to a buffer-based approach.
What does this mean? "buffer-based approach' thanks
Perhaps TMK and QMK do something similar under the covers?
{
"from": {
"modifiers": {
"optional": [
"any"
]
},
"simultaneous": [
{
"key_code": "spacebar"
},
{
"key_code": "m"
}
],
"simultaneous_options": {
"key_down_order": "strict",
"key_up_order": "strict_inverse",
"to_after_key_up": [
{
"set_variable": {
"name": "SpaceFN",
"value": 0
}
}
]
}
},
"parameters": {
"basic.simultaneous_threshold_milliseconds": 500
},
"to": [
{
"set_variable": {
"name": "SpaceFN",
"value": 1
}
},
{
"key_code": "grave_accent_and_tilde"
}
],
"type": "basic"
}
,
{
"type": "basic",
"from": {
"key_code": "m",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "grave_accent_and_tilde"
}
],
"conditions": [
{
"type": "variable_if",
"name": "spacefn_mode",
"value": 1
}
]
}
great to see another serious attempt for dual role keys on linux! i just want to ask my quick question, what is the main difference between your implementation and AHM (at home modifier)? (https://gitlab.com/at-home-modifier/at-home-modifier-evdev/wikis/home)
thanks! i hope this space in the linux ecosystem can be steadilty filled more more tools in the future... maybe it would be worth inquiring if the xorg-input-evdev maintainers would be interested in merging the code one day?
one other question, is there any reason this could not be implemented in libinput/xf86-input-libinput?
thanks! i hope this space in the linux ecosystem can be steadilty filled more more tools in the future... maybe it would be worth inquiring if the xorg-input-evdev maintainers would be interested in merging the code one day?
SpaceFn is so niche that I doubt the xorg-input-evdev maintainers would want the complexity in their codebase. It would be better to find a way for input mangling algorithms such as SpaceFn to live comfortably side by side with xorg-input-evdev.
I recently came across caps2esc (https://github.com/oblitum/caps2esc), which is a step in that direction. It runs as a separate process, uses libevdev to read events from evdev, and writes them (with modifications) to a new device, which xorg-input-evdev can then read from.one other question, is there any reason this could not be implemented in libinput/xf86-input-libinput?
I haven't looked at the code, but I don't see a fundamental reason why it can't be done. I chose to patch xorg-input-evdev simply because that's what the Linux distribution that I run uses.
After seeing this thread a couple of weeks ago, I decided to try the SpaceFn concept on my boards that support TMK and QMK after reading about "tap keys" that are built into those Firmwares.
So I first tried it on my Redscarf board, and went to the TMK programming site and set the spacebar as a dual-roll function key. When tapped, it acts as a normal spacebar, but when held, it becomes my function key. It works great! It makes it super easy to dab F5 to refresh a web page or or use the Function keys when gaming without having to fumble around looking for that dedicated Fn key - just hold the space bar, and they are instantly accessible without moving your hands.
So then I grabbed one of my other boards that uses QMK and went to kbfirmware.com, and assigned the space bar to L(T) [Layer Toggle]. Then I assigned the toggled layer to Layer 1, and the keypress character to "space". The code looks like this - LT(1,SPACE). This also worked perfectly.
AFAIK, the default time limit for tap vs hold is 200ms on these firmwares. So as long as your tap/hold time is shorter than that, you'll always get a space inserted when you are typing. For me, it's been at least 99% accurate on my taps. I believe you can change this setting if you know your way around QMK.
In TMK, I also bound Layer 1 to backlight ON, so that whenever layer 1 is active, the whole keyboard lights up at full brightness (I normally have backlight off or on low). What this does is give me a visual cue that the momentary layer switch is active. So when you press that space bar, after a moment, the kb lights up and informs you it's ready for your secondary input.
This is really a brilliant way to use an Fn key, and now I'm annoyed when I use a keyboard that doesn't have this option available :-P
EDITS: clarity
After seeing this thread a couple of weeks ago, I decided to try the SpaceFn concept on my boards that support TMK and QMK after reading about "tap keys" that are built into those Firmwares.
So I first tried it on my Redscarf board, and went to the TMK programming site and set the spacebar as a dual-roll function key. When tapped, it acts as a normal spacebar, but when held, it becomes my function key. It works great! It makes it super easy to dab F5 to refresh a web page or or use the Function keys when gaming without having to fumble around looking for that dedicated Fn key - just hold the space bar, and they are instantly accessible without moving your hands.
So then I grabbed one of my other boards that uses QMK and went to kbfirmware.com, and assigned the space bar to L(T) [Layer Toggle]. Then I assigned the toggled layer to Layer 1, and the keypress character to "space". The code looks like this - LT(1,SPACE). This also worked perfectly.
AFAIK, the default time limit for tap vs hold is 200ms on these firmwares. So as long as your tap/hold time is shorter than that, you'll always get a space inserted when you are typing. For me, it's been at least 99% accurate on my taps. I believe you can change this setting if you know your way around QMK.
In TMK, I also bound Layer 1 to backlight ON, so that whenever layer 1 is active, the whole keyboard lights up at full brightness (I normally have backlight off or on low). What this does is give me a visual cue that the momentary layer switch is active. So when you press that space bar, after a moment, the kb lights up and informs you it's ready for your secondary input.
This is really a brilliant way to use an Fn key, and now I'm annoyed when I use a keyboard that doesn't have this option available :-P
EDITS: clarity
Sweet, gonna try this after I install Hasu's controller. I tried using TouchCursor for a while, but having the space register after I release the spacebar was really messing with how I type. Will this function similar to that?
I use the capslock key as fn. A feature that was on my Pok3r. I loved it so much I program all my keyboards with it.
Other shortcuts I love having programmed, including other pok3r shortcuts are:
cpslck + space = enter
cpslck + ; = backspace
This greatly reduces the strain on my right pinky. Once you try it, you wouldn't believe how far you had to stretch your fingers to reach those super common buttons.
I don't like the idea of the space being a modifier when depressed.
After seeing this thread a couple of weeks ago, I decided to try the SpaceFn concept on my boards that support TMK and QMK after reading about "tap keys" that are built into those Firmwares.
So I first tried it on my Redscarf board, and went to the TMK programming site and set the spacebar as a dual-roll function key. When tapped, it acts as a normal spacebar, but when held, it becomes my function key. It works great! It makes it super easy to dab F5 to refresh a web page or or use the Function keys when gaming without having to fumble around looking for that dedicated Fn key - just hold the space bar, and they are instantly accessible without moving your hands.
So then I grabbed one of my other boards that uses QMK and went to kbfirmware.com, and assigned the space bar to L(T) [Layer Toggle]. Then I assigned the toggled layer to Layer 1, and the keypress character to "space". The code looks like this - LT(1,SPACE). This also worked perfectly.
AFAIK, the default time limit for tap vs hold is 200ms on these firmwares. So as long as your tap/hold time is shorter than that, you'll always get a space inserted when you are typing. For me, it's been at least 99% accurate on my taps. I believe you can change this setting if you know your way around QMK.
In TMK, I also bound Layer 1 to backlight ON, so that whenever layer 1 is active, the whole keyboard lights up at full brightness (I normally have backlight off or on low). What this does is give me a visual cue that the momentary layer switch is active. So when you press that space bar, after a moment, the kb lights up and informs you it's ready for your secondary input.
This is really a brilliant way to use an Fn key, and now I'm annoyed when I use a keyboard that doesn't have this option available :-P
EDITS: clarity
Sweet, gonna try this after I install Hasu's controller. I tried using TouchCursor for a while, but having the space register after I release the spacebar was really messing with how I type. Will this function similar to that?
Yes, with SpaceFN, space is always registered when you release the key. Think about it: no system can guess if you press space to invoke a special function or if you just want to type a space, so it is impossible to register a space before you actually release it.
It does feel strange for a while, but don't underestimate your brain: it will definitely adapt. After a while you don't even think about it anymore.
Hasu's controller(s) can be programmed with Hasu's brilliant TMK driver, which includes SpaceFN.
You will have to compile TMK with:
make KEYMAP=spacefn
to get SpaceFN (this is from the top of my head, please check with the documentation).
Under Linux, I actually have to type this command to compile TMK and start the firmware flashing procedure (I'm using a GH60):
sudo make KEYMAP=spacefn dfu
(the "dfu" part is to start flashing the formware immediately).
Hasu's implementation is very, very well done, and from what other people say, it's better than TouchCursor.
I think it's really state of the art and it works beautifully with SpaceFN.
Yea I ended up just changing the modifier key to caps lock instead of space, but I'm definitely gonna try it again with QMK. I noticed I would push a key or two while space was still depressed, which was throwing off my typing a lot.
Hoping I can get it to where I like it with QMK, otherwise I'll prolly end up putting in on caps lock again lol.
Yea I ended up just changing the modifier key to caps lock instead of space, but I'm definitely gonna try it again with QMK. I noticed I would push a key or two while space was still depressed, which was throwing off my typing a lot.
Hoping I can get it to where I like it with QMK, otherwise I'll prolly end up putting in on caps lock again lol.
The whole point of SpaceFN is to use space. It was designed around using space as the Fn key, so the design is completely off if you use CapsLock. By this I mean that if you want to use CapsLock as the Fn key, you can build a layout around this idea, and you will not end up with the same layout as SpaceFN.
Naturally there is nothing, and no one, preventing you from doing it, but in this case maybe you would like to try GuiFN, which is another layout I have designed after SpaceFN, to address the objection some -and I- had about SpaceFN.
It's not that SpaceFN is wrong, it's just that some people have a hard time adapting to it, which is totally understandable, and also that some keyboards would not allow to redefine the function of the space key.
I have described GuiFN here:
https://geekhack.org/index.php?topic=57723.msg1313182#msg1313182
I have used both SpaceFN and GuiFN for several months and I could work on both. I even had customized keycaps sets made for both, so I have eaten my own dog food, so to speak. :)
GuiFN does not have the convenience of this space key that is always under your thumb, but it definitely avoids the problems with the unusual behaviors in SpaceFN. It's more familiar, right from the start.
Yea I ended up just changing the modifier key to caps lock instead of space, but I'm definitely gonna try it again with QMK. I noticed I would push a key or two while space was still depressed, which was throwing off my typing a lot.
Hoping I can get it to where I like it with QMK, otherwise I'll prolly end up putting in on caps lock again lol.
The whole point of SpaceFN is to use space. It was designed around using space as the Fn key, so the design is completely off if you use CapsLock. By this I mean that if you want to use CapsLock as the Fn key, you can build a layout around this idea, and you will not end up with the same layout as SpaceFN.
Naturally there is nothing, and no one, preventing you from doing it, but in this case maybe you would like to try GuiFN, which is another layout I have designed after SpaceFN, to address the objection some -and I- had about SpaceFN.
It's not that SpaceFN is wrong, it's just that some people have a hard time adapting to it, which is totally understandable, and also that some keyboards would not allow to redefine the function of the space key.
I have described GuiFN here:
https://geekhack.org/index.php?topic=57723.msg1313182#msg1313182
I have used both SpaceFN and GuiFN for several months and I could work on both. I even had customized keycaps sets made for both, so I have eaten my own dog food, so to speak. :)
GuiFN does not have the convenience of this space key that is always under your thumb, but it definitely avoids the problems with the unusual behaviors in SpaceFN. It's more familiar, right from the start.
That is an interesting new idea. It may work better with the right Super key for FN instead. The one you proposed makes using it one hand quite difficult. I'll stick with Space-FN, it rocks.
Yea I ended up just changing the modifier key to caps lock instead of space, but I'm definitely gonna try it again with QMK. I noticed I would push a key or two while space was still depressed, which was throwing off my typing a lot.
Hoping I can get it to where I like it with QMK, otherwise I'll prolly end up putting in on caps lock again lol.
The whole point of SpaceFN is to use space. It was designed around using space as the Fn key, so the design is completely off if you use CapsLock. By this I mean that if you want to use CapsLock as the Fn key, you can build a layout around this idea, and you will not end up with the same layout as SpaceFN.
Naturally there is nothing, and no one, preventing you from doing it, but in this case maybe you would like to try GuiFN, which is another layout I have designed after SpaceFN, to address the objection some -and I- had about SpaceFN.
It's not that SpaceFN is wrong, it's just that some people have a hard time adapting to it, which is totally understandable, and also that some keyboards would not allow to redefine the function of the space key.
I have described GuiFN here:
https://geekhack.org/index.php?topic=57723.msg1313182#msg1313182
I have used both SpaceFN and GuiFN for several months and I could work on both. I even had customized keycaps sets made for both, so I have eaten my own dog food, so to speak. :)
GuiFN does not have the convenience of this space key that is always under your thumb, but it definitely avoids the problems with the unusual behaviors in SpaceFN. It's more familiar, right from the start.
Yea I ended up just changing the modifier key to caps lock instead of space, but I'm definitely gonna try it again with QMK. I noticed I would push a key or two while space was still depressed, which was throwing off my typing a lot.
Hoping I can get it to where I like it with QMK, otherwise I'll prolly end up putting in on caps lock again lol.
I referred to the right Alt. It is true that it is used for alt graphics, like in my case, but trying to use the key next to it is hard.
The whole point of SpaceFN is to use space. It was designed around using space as the Fn key, so the design is completely off if you use CapsLock. By this I mean that if you want to use CapsLock as the Fn key, you can build a layout around this idea, and you will not end up with the same layout as SpaceFN.
Naturally there is nothing, and no one, preventing you from doing it, but in this case maybe you would like to try GuiFN, which is another layout I have designed after SpaceFN, to address the objection some -and I- had about SpaceFN.
It's not that SpaceFN is wrong, it's just that some people have a hard time adapting to it, which is totally understandable, and also that some keyboards would not allow to redefine the function of the space key.
I have described GuiFN here:
https://geekhack.org/index.php?topic=57723.msg1313182#msg1313182
I have used both SpaceFN and GuiFN for several months and I could work on both. I even had customized keycaps sets made for both, so I have eaten my own dog food, so to speak. :)
GuiFN does not have the convenience of this space key that is always under your thumb, but it definitely avoids the problems with the unusual behaviors in SpaceFN. It's more familiar, right from the start.
That is an interesting new idea. It may work better with the right Super key for FN instead. The one you proposed makes using it one hand quite difficult. I'll stick with Space-FN, it rocks.
Well, the right Super key is the key I suggest in GuiFN.
Ergonomically, the right Alt key would have been even easier to reach. Unfortunately the right Alt key is called AltGr in some international layouts, and is used extensively to compose special characters, like accentuated ones. So using the AltGr key as the Fn key was not possible.
Well, the right Super key is the key I suggest in GuiFN.
Ergonomically, the right Alt key would have been even easier to reach. Unfortunately the right Alt key is called AltGr in some international layouts, and is used extensively to compose special characters, like accentuated ones. So using the AltGr key as the Fn key was not possible.
I wanted to try this on my laptop, but the only existing Linux implementation I could find involves recompiling the X11 keyboard driver, which is... not easy.
So I've written one that uses evdev/uinput and runs in userspace. It's trivial to compile and it works both for X11 and in the Linux console. I've just got a very simple keymap in it to try, hopefully someone else finds it useful.
You can find it here: https://github.com/abrasive/spacefn-evdev
Unfortunately, I'm getting linker errors. The linker does not find the following symbols:
libevdev_uinput_write_event
libevdev_next_event
libevdev_new_from_fd
libevdev_uinput_create_from_device
libevdev_grab
Any idea?
Unfortunately, I'm getting linker errors. The linker does not find the following symbols:
libevdev_uinput_write_event
libevdev_next_event
libevdev_new_from_fd
libevdev_uinput_create_from_device
libevdev_grab
Any idea?
Thanks for trying it out!
Can you open an issue on the Github project so we don't spam up the thread? Let me know what pkg-config --libs libevdev has to say, and if you can tell me exactly what version of libevdev you have that'd be useful too.
{
"description": "SpaceFN: Space+u to Home, Space+o to End",
"manipulators": [
{
"conditions": [
{
"name": "spacefn_mode",
"type": "variable_if",
"value": 1
}
],
"from": {
"key_code": "u",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "home"
}
],
"type": "basic"
},
{
"conditions": [
{
"name": "spacefn_mode",
"type": "variable_if",
"value": 1
}
],
"from": {
"key_code": "o",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "end"
}
],
"type": "basic"
}
]
},
{
"description": "SpaceFN: Space+h to Page Up, Space+n to Page Down",
"manipulators": [
{
"conditions": [
{
"name": "spacefn_mode",
"type": "variable_if",
"value": 1
}
],
"from": {
"key_code": "h",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "page_up"
}
],
"type": "basic"
},
{
"conditions": [
{
"name": "spacefn_mode",
"type": "variable_if",
"value": 1
}
],
"from": {
"key_code": "n",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "page_down"
}
],
"type": "basic"
}
]
},
{
"description": "SpaceFN: Space+u to Page Up, Space+o to Page Down",
"manipulators": [
{
"conditions": [
{
"name": "spacefn_mode",
"type": "variable_if",
"value": 1
}
],
"from": {
"key_code": "u",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "page_up"
}
],
"type": "basic"
},
{
"conditions": [
{
"name": "spacefn_mode",
"type": "variable_if",
"value": 1
}
],
"from": {
"key_code": "o",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "page_down"
}
],
"type": "basic"
}
]
},
{
"description": "SpaceFN: Space+h to PC Home, Space+n to PC End",
"manipulators": [
{
"conditions": [
{
"name": "spacefn_mode",
"type": "variable_if",
"value": 1
}
],
"from": {
"key_code": "h",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "left_arrow",
"modifiers": "left_command"
}
],
"type": "basic"
},
{
"conditions": [
{
"name": "spacefn_mode",
"type": "variable_if",
"value": 1
}
],
"from": {
"key_code": "n",
"modifiers": {
"optional": [
"any"
]
}
},
"to": [
{
"key_code": "right_arrow",
"modifiers": "left_command"
}
],
"type": "basic"
}
]
},
I'm trying a modified version of this SpaceFN idea. I'm typically a proponent of more rather than less keys, and a physically separated nav cluster, but this idea lends itself especially well to crammed keyboards such as those found on a laptop.
It's definitely taking a bit of effort to adjust to, especially when using the layered arrow keys with a modifier like Control (for forward/back web browsing) where I really have to stop completely and think about the key press sequence, but I can see the value in this idea.
Initially I had started off with arrow keys on the left hand, but found that it interfered too much with Control-C/V/X as mentioned earlier in this thread. Moved to the right hand and things became less confused.
There's an unexpected downside with running this at the software level- Touchcursor takes a little while to autostart on computer bootup (even on a totally modern PC). It's long enough to have bitten me a couple of times and I just have to wait for a while before the remaps take effect.
Overall, from the perspective of a TKL user, I am really liking this idea.
Anyway, here is my general advice after all these years experimenting with small keyboards:
- If you can, do not ever purchase a keyboard that has no dedicated arrow keys, no matter how good it looks, because your productivity will suffer.
Anyway, here is my general advice after all these years experimenting with small keyboards:
- If you can, do not ever purchase a keyboard that has no dedicated arrow keys, no matter how good it looks, because your productivity will suffer.
My own counterpoint:
Try many things, especially boards without dedicated arrow keys.
In my case, and I'm sure many others, my productivity has vastly improved from a lack of dedicated arrow keys—and further, by using an ortholinear layout, and further still, from 40% size.
The less my fingers have to travel (40%), and to travel to a more consistent destination (ortho) results in far fewer typos. Using SpaceFN and other layers, and even chorded combinations, vastly dwarfs any convenience provided by arrow keys. I can access all nav keys from either home row or adjacent to it. Zero time wasted moving to an arrow cluster and then finding my homing key when moving my right hand back.
Take that a step further and invest in learning the advanced bindings of your text editor (for me vim, but others are fine too) and you will see even further performance gains.
If you type for a living, and you are prepared to work to improve your typing and workflow, you absolutely should experiment. Keyboards, layouts, plover—everything. But it requires work, so you have to be prepared to buckle down and put up with a performance loss until your ability ramps up.