The SpaceFN layout: trying to end keyboard inflation

[spiceBar]

In this post I introduce a layout that is designed with a future 60% keyboard in mind, but which actually works on all standard keyboards, even full sized ones. It may already be useful as an alternative to the default layouts of the Poker X, Poker II and HHKB. It may even be useful for the Ergodox or similar ergonomic keyboards.

It is not a virtual thing. You can already try it on your own keyboard.

I'm not going to create a keyboard myself. I'm just trying to contribute and hopefully improve on the current 60% layouts.

The SpaceFN layout is based on ideas that are not mine. So I would first like to credit the following people:
- Edgar MATIAS for his work on the dual use of standard keys as modifiers, 20 years ago.
- Hasu for his terrific TMK firmware.
- Lydell for implementing it for Windows (as an AHK script).
- The authors/users of vi/vim for championning the idea of having arrows in the home row.
(links to credits at the end of this post)

So here is a proposed 60% keyboard (let's say it has Cherry MX or Topre switches):




This keyboard is just the alphabetic (or "typewriter") cluster of a standard PC keyboard. We have just replaced the backquote ( ` ) key with the Esc key for convenience, but we actually do not even need to. Keeping the backquote on top left is not a problem.

No learning curve, you can start using it immediately. Every key does what you think it does.

...until you need to move the cursor. There are no arrow keys! There is not even an Fn key to access another layer of functions, like on all 60% boards!

So how do you access the arrow keys and all the other missing keys?

---> YOU PRESS THE SPACE BAR AND HOLD IT!

And then while holding space you press another key. Here is what the keys do when you press and hold space:




NOTE: all the keys that have no legend do the thing they do when space is not pressed.

The space bar is our Fn key, hence the name of the layout: SpaceFN.

Now from the two pictures above, you can tell that this keyboard can do everything a standard keyboard can do.

There are a few things that should be configurable. For example you should be able to have the backquote still in place at the top left of the keyboard, you should be able to use WASD or HJKL for the arrows if you wish... And of course you should be able to swap Ctrl and CapsLock.


I have been using this layout exclusively for more than 10 days now, mainly on a Poker, but also on a Realforce 87U without ever using the dedicated arrows and functions keys. It just works. You may wonder how it is possible, because we are using the space bar all the time, and not for the purpose of triggering navigation keys, so it MUST interfere and create all kind of problems!? But it does not! There are various safeguards in the design of the layout and in the way it is implemented that ensure that it is working as expected.

You can already try this layout by yourself on your computer (if you use Windows, a Mac or a keyboard using the TMK firmware). At the end of this post you will find how to test the layout if you are interested.


Now let's talk about the pros and cons of this layout.
PROS:
- The basic layout is totally standard.
- If you touch type, you can touch type on it without re-learning anything.
- You can easily find replacement keycaps: they are all standard not only in size but also in labeling.
- You can type and edit/navigate without leaving the home row (hello VIM users!).
- It works well on all international layouts, not just on QWERTY. It works on ISO keyboards.
- Our Fn key (the space bar) is huge and in the center of the keyboard. With one hand, any hand, you can easily access all of the Fn layer functions, including F1...F12. This leaves your other hand free to press Crtl, Shift or Alt to create key combinations.
- The Fn key (the space bar) always sits under your thumbs. You never have to ask yourself where it is. You can't miss it.
- The location of the arrow keys has been chosen so your index finger sits on the "J" key, which has a little bump on it. It's easy to find without looking at the keyboard, and it's where your index finger should be anyway for proper touch-typing. As an option, the arrows could be on HJKL or WASD instead (I have not yet worked out the layouts for these but I don't foresee any problem).

CONS:
- The space bar does not auto-repeat. To compensate, space+B ("Blank") is an autorepeating space.
- When you type a space, the space character appears only when you release the key.
- It may not be suitable at all for gaming, in part because of the previous points. To compensate, a special mode, that should be easy to enable, should be provided. In this mode, space would act in a standard way. Another key will act as the Fn key. CapsLock looks as a good candidate. In this mode CapsLock pressed alone toggles the capitals mode, CapsLock pressed with another key allows to access the navigation/function keys.
- You have to learn the navigation keys layout. I admit that it takes a few hours to be comfortable with it.

Here are some notes about the design:
- By design, the strong fingers are heavily favored in the Fn layout. The pinky is almost not used.
- Unused keys: if you hold the space bar and press a key that has no function in the Fn layout, you get exactly the same result as if you were not holding space.
- Most keys in the Fn layer have been chosen to be easily reachable with a natural, arc-shaped, extension (not bending) of the right hand. The right hand has not been chosen with the idea of favoring right-handed people (read on).
- The left side of the keyboard has nothing in the Fn layout. This is on purpose. This part of the keyboard has many frequently used shortcuts that we do not want to interfere with: Ctrl-C, Ctrl-X and Ctrl-V are the most important ones. When you edit text, you can press and hold space and then  navigate to some point, select text there, cut it or copy it to the clipboard, move somewhere else, and finally paste it. You can do all this without ever releasing the space bar. So while copying or moving text, you do not have to think about the space bar.
- There is an Esc key in the Fn layer, because you may want to have direct access to the backquote in the basic layout. Also, it may be convenient to be able to press Esc without releasing the space bar.
- The backquote and tilde keys have been repeated in the Fn layout, to make them more accessible. This is for convenience and is not required.
- The SpaceFN layout loves soft space bars. For example on the Realforce 87U and FC660C, removing the spring under the space bar helps. A keyboard designed specially for SpaceFN should have a space bar that is easy to press and hold.
- The SpaceFN layout works well with a flipped space bar. It makes pressing and holding space easier. Naturally it's not required, it's just more comfortable.


Let's end with a totally original 60% keyboard never seen anywhere else: 




And its Fn layer:




(interestingly, this keyboard only uses STANDARD keys)


Want to try SpaceFN?

Windows users: Lydell has written a port of SpaceFN as an AHK script for Windows. It can be downloaded from here:
  https://github.com/lydell/spacefn-win

Edit 2015.02.02: it looks like TouchCursor (http://touchcursor.sourceforge.net) is even better than AHK (AutoHotKey) for the purpose of implementing SpaceFN under Windows.

Mac users: below is the KeyRemap4MacBook script that can be used on a Mac (any Mac, not just on MacBooks) to try the fully functional layout. The script starts with comments explaining how to install and activate it. So please read this part. If you need more help installing, please just ask in this thread and I'll help you.

TMK firmware users: I think Hasu will be glad to provide an implementation of SpaceFN for its TMK firmware. An interesting bit is that Hasu has designed a replacement controller for the HHKB that allows to turn it into a fully programmable keyboard. He has also created a converter that allows a PS/2 or USB keyboard to become a fully programmable keyboard. This allows to use SpaceFN on all kind of existing keyboards without modding them. NOTE: will work with a USB keyboard only if is PS/2 compatible, i.e. it works when plugged into a PS/2 port with a passive adapter.

Linux users: I'm looking for help to port SpaceFN to Linux!


Credits links:
- Edgar MATIAS for his early work on the use of space as a dual role modifier:
    http://edgarmatias.com/papers/hci96/
- The dual role modifiers thread on Geekhack, from which I first learned about the idea:
    https://geekhack.org/index.php?topic=41685.0

Please let me know if I should give credit to someone else. As I said, these ideas are not mine, they have been around for quite a while.





Here is the KeyRemap4MacBook script:

Code: [Select]

<?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>


[stancato9]

I really like the idea of the spacebar FN key. It feels a lot more natural than having it anywhere else and doesn't throw off the positioning of your hands.

[tbc]

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.

[spiceBar]

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.

The Filco Minila got it wrong by adding two Fn keys that are eating the space bar when it was simply possible to use the space bar as in the SpaceFN layout shown above.

It almost feels like they wanted to use the space bar. At least they understood that the thumbs are the perfect fingers to use for the Fn key.

Ironically, you can use SpaceFN on the Minila.

[dante]

This is absolutely brilliant.  Once seen it can't be unseen!

[Puddsy]

And this is why I love the miniLA

It's kinda like this but with actual arrow keys

[dorkvader]

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)

Using the spacebar as function allows me to do both (with on key!) I very much like it.

Thanks for the good work. Time to look into reprogramming my keyboards

[jeffgran]

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.

[spiceBar]

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.

Your feedback on this experiment will be much appreciated.

[durandalx]

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?

[spiceBar]

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.

My view on this point is that repeating by double-press will probably be confusing because it adds something else to keep in mind when you use the space bar.

But I don't really know, I haven't been able to try this and to see how many times it would get in the way.

Ideally, your keyboard should support the SpaceFN layout so you don't rely on any software installed on your computer. So the option to allow space to repeat by double-pressing it should be an option offered by the keyboard itself.

You should also try the layout by yourself and decide if space-B does the job for you or if you cannot adapt to this. Things that seem difficult before you try them sometimes end up being a non-issue.

[tbc]

are the mods disabled in the second layer?

because I regularly use ctrl+shift+cursor to move by words at a time.

EDIT:

nvm, found it in your pros list.

[kenmai9]

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


[spiceBar]

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


The point of the SpaceFN layout is that we use the space bar as the Fn key. The Fn layer itself is not written in stone.

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

Then on top of the basic layer (IJKL or HJKL or WASD) a handful of options:
- swap Ctrl and CapsLock
- Esc or backquote in the top left
- ...and a few others, but this list will have to be kept short

Hasu's firmware is already able to manage several Fn layers, so we already have a working solution for SpaceFN embedded in the keyboard itself. It's just that I am not sure if and how it can deal with the options (Esc or backquote, etc.). And with a programmable controller you would not be limited to the standard layers and options anyway.

Obviously for a software implementation of SpaceFN (AHK or KR4MB) there is no problem. You can tweak it easily.

For the last twelve days I have been using the IJKL layer because it is the most natural for me (it's the classical inverted T cluster I use all the time). I really wanted to use only one layer at first to see how long it takes to become proficient with it, and how well it does.

But I knew from the start that it was necessary to provide a choice of layers.

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?

[lydell]

Installation was pretty confusing at first (installing Dual).

Ah, that's too bad. How can I improve it? Better documentation? Sometimes it's really hard to describe stuff to others that you've done yourself so many times. Glad you sorted it out, though

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.

You'll get used to it, just give it some time At least I got used to it pretty quickly. I've done the same thing to keys on the home row; Having _letters_ coming on keyup is much more difficult to get used too in comparison to space, which again makes space such a good candidate for a dual-role key.

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


The best thing would be to merge the spacefn-win.ahk file and your file containing that code. It's always easier to work with fewer remapping files in AHK. Did you encounter any specific problems?

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.

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.)

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

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.

HJKL is of course wanted by vim users. But there's also a point to using HJKL, besides being vim friendly. Don't you use up and down much more than left and right? At least I do. And I use down more than up, probably since we read from top to bottom. So it makes sense to put down on the strongest finger on the home row, and up on the next strongest one. Then I use right a lot more than left. That's probably because I'm a vim user though. It's just easier to edit forwards than backwards in vim. So it is more important to have right directly under a finger than left. Finally, with both IJKL and HJKL you have to reach for one key. It's better to reach for left (H), than up (I) in my opinion. So HJKL as an option is definitely worth checking out.

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.

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?

The vim order is H=Left, J=Down, K=Up, L=Right. I had never heard about HJKL before using vim, so the only "standard" I know of is the vim keybindings. However, I don't think they are useful in this case.

[spiceBar]

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.)

So this should be added as an option whenever possible. In some implementations, for example with KeyRemap4MacBook it is not possible. However it is possible with AHK and Hasu's TMK firmware.

I still believe that it should be disabled by default, but we really need to try it for a while and see if it's safe enough to be enabled by default. People will find intuitively that double-press allows repeat, they will not find that space+B is a repeating space. But the layout needs some cheat sheet somewhere on the keyboard anyway.

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.

You are absolutely right, but people will want WASD anyway. They won't even consider SpaceFN if WASD is not provided. Then they will try it and finally settle for IJKL or HJKL.

So we need WASD.

Not interfering with the shortcuts on the left of the keyboard is not mandatory. It's convenient to be able to select a piece of text, copy it to the clipboard with Ctrl-C and then go somewhere else to paste it all of this without ever releasing the space bar, but if the C key is overloaded in the Fn layer the Ctrl-C shortcut still works as it has always worked. It's just that the user will have to release space to do Ctrl-C.

So let's people have WASD and then switch to IJKL or HJKL when they realize that it's more convenient.

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.

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?

[Findecanor]

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

For IJKL, I am partial to the Numpad layout but with Down on the equivalent to 5 (K).
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.

What do VIM users want for Home/End?

Let me heretical here for a moment ( ) and suggest A for Home and E for 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.

[spiceBar]

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

For IJKL, I am partial to the Numpad layout but with Down on the equivalent to 5 (K).
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.

What do VIM users want for Home/End?

Let me heretical here for a moment ( ) and suggest A for Home and E for 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.

The IJKL layout is already done (see my OP). Naturally it is still possible to change it if a large consensus for a change emerges.

For HJKL, yes H=left, J=down, K=up and L=right.

A and E for Home and End have this problem: put your hand on the keyboard so you can use HJKL. Naturally you are going to use your right hand, OK?

Now, while still pressing space, try to press A or E.

Not easy I think.

[kenmai9]

G for end and Y for home?

[JayG30]

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.

[Matias]

Cool idea.

You'll have to adjust your typing style slightly, to avoid the spacebar interfering, but it's do-able.

It will also constrain your typing speed somewhat, but probably won't slow you down much if you're not faster than say 80wpm.

As for layout, I'm partial to this...

[Air tree]

This would be quite nice for gaming for me. I can hit all the f keys with one hands without taking my hand off the mouse. And that results in quick fkey movements when in games that use fkeys Alot.


Same goes for the arrow keys.

[terran5992]

Might not work for FPS gamers. Cuz you have to jump and maybe switch weapons at the same time

[hasu]

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?

I'm long time vi(m) user too, but I don't want to use $0BF outside the editor at all.
I've placed Home/PgUp/PgDn/End on YUIO(or NM<>) with my layout, this fingering also completely conform to lydell's theory Tougher fingers are used for useful keys; PgUp and PgDn. And I'm sure this is natural to vi(m) users due to analogy of HJKL.

[spiceBar]

So after listening to your input, I have designed 3 additional SpaceFn layers:
- the IJKL2 layer, which is close to the Matias Optimizer keyboard
- the HJKL layer, which should please old Unix users and current vim users
- the WASD layer, for those of you that have developed muscle memory over hundreds of hours of gaming

So we now have a choice of 4 SpaceFN layers, plus the option to have the Esc or backquote in the basic layout.


First, here is the basic layout of the keyboard:




For those who use the backquote frequently, the basic layout can also be:




Here is the first IJKL SpaceFN layer. The functions in this layer are enabled when the space bar is pressed and hold:




If you have kept the backquote in the basic layout, then space+backquote does Esc, but you can also do it with space+E.


All the keys that do not have any legend on them act as if the space bar was not pressed. This is very convenient because, for example, space+Ctrl+C still does "copy to clipboard".


Here is the second IJKL SpaceFN layer. This layer looks like the navigation shortcuts on the Matias Optimizer, and also look like the original numpad on the IBM PC XT keyboard.




Here is the HJKL layer. Depending on how large your hand is, and on various other factors, you can use the Home/Down/Up/End cluster that is above the HJKL cluster, or the one that is below.




Finally, here is the WASD SpaceFN layer. If you have done a lot of gaming, it may work for you. But clearly, having the navigation cluster on the left of the keyboard is not optimal and doesn't fit well with the SpaceFN idea. But it may work for you, so here it is:

[lydell]

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?

[spiceBar]

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.

I understand your point but whenever possible it is better to keep things simple.

For Alt-left, you can either use the other hand to hold the left Alt, or simply use your ring finger for the right Alt, your thumb on the space bar as usual, and your index finger for J (left). I think using the pinky for right Alt is more difficult than using the ring finger.

So it looks like we would have to add a Fn-Lock feature for a very specific usage. Worse: the Fn-Lock is not even needed, it would be for convenience (so that you can just use one finger instead of two for the up of down arrow).

[spiceBar]

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?

Menu: the contextual menu key is only needed in my "SpaceFN professional" mockup, the one that looks like an HHKB, because this keyboard does not have the Menu key. For a standard 60% keyboard, it is not needed.

Only the first IJKL layout has extra backquote and tilde keys, because these keys are used for other purposes in the other layouts. Backquote and tilde in the IJKL area is just a convenience. If you have opted for Esc on top left, space+Esc gets you the backquote and space+Shift+Esc does the tilde.

Yes, the second IJKL layout is supposed to have 2 down keys. I have followed the idea of the Matias Optimizer keyboard.

The HJKL overloads Y, and you are right, on a German keyboard this will force the user to release space when he wants to do Ctrl-Z. It is not really a problem in the sense that the layout still works perfectly (there is no key collision actually). It's just that a German user would have to release space to do Ctrl-Z, instead of being able to keep it pressed. Being able to keep it pressed gives a better workflow. I have not gotten feedback on my HJKL layout yet. If people are happy with Home/PgDn/PgUp/End under HJKL, we could free the row above HJKL. Personally, I have not been able to find out where the Home/PgDn/PgUp/End cluster was easier to reach. I can reach it as easily on both locations, but it's just me.

[Matias]

• 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.

Our nav cluster is patterned after the NumLock-Off cluster on PC number pads — which accounts for the lower Down key.  The other Down key follows the standard inverted-T pattern.

[hasu]

I tried SpaceFN(IJKL) layout on GH60 with tmk_keyboard, it works.

https://github.com/tmk/tmk_keyboard/blob/master/keyboard/gh60/keymap_spacefn.c

Code: [Select]

/*
 * 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
};


[spdx]

Thanks for sharing.  This is a great idea for a 60% keyboard. 

[TacticalCoder]

- 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)
 

[spiceBar]

- 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 have played LodeRunner on the early PCs, but I don't remember which keys it used.

The IJKL keys seem very natural. For proper touch-typing, you are supposed to have your index finger on J, which has this little tactile bump, so your finger are already in IJKL (or some will have their finger on JIO).

I am not really a touch-typist. At this point I have spent 32 years typing on keyboards. I "almost" touch-type, but a computer keyboard does not make that easy, especially when you spend a lot of time developing software.

The problem is that you often have to hit symbols and navigation keys. So your hands spend so much time far from the home position that touch-typing is not that efficient. I think most developers end up developing their own way to type, which involve peeking at the keyboard quite often.

But I have been using SpaceFN for almost 3 weeks now, and something interesting is happening: I'm losing my bad habits.

Since I'm using a small keyboard now, a Poker X, my hands do not have to move much to reach all the keys.

To use the arrows, I'm forced to keep my right hand on the home position, which is good. Using the arrows requires pressing and holding space first (like you do for Shift or Control), so it's not as fast as having dedicated keys. But I don't have to move my hand to reach them, and I don't have to move it back to continue typing. So it's clear that I'm not slowed down at all by not having dedicated arrow keys.

I find myself looking less and less at the keyboard and touch-typing more and more often.

I had so much muscle memory for a standard or TKL layout that as much as I love my 60% boards I found myself still more comfortable on the Realforce. Both the Poker and the Realforce are connected to my computer, so I can switch between them easily.

But I keep using the Poker all day long now, which is a good testimony that the SpaceFN layout works.

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.

[TacticalCoder]

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.

I hear you... I'm a software dev too and I know many coders who do not touch-type. That said on GH and DT many people do touch-type! I learned to touch-type more than 15 years ago and I always have my hands on the home row: which is how I ended up with {ijkl} 

I know about the 'fn' key on the HHKB: it's kinda sucky and the arrows are poorly located (and not in an inverted T fashion). I'm using the left alt (well, the key at the left of the space bar, whatever we want to call it: it can be remapped with DIP-switches on the HHKB) as my modifer.

I like your setup and started modification mine: mod + 'e' for 'escape' just makes sense (no more pinky stretching and hand movement), home, end, etc.

A great idea you had there.

Don't know how to make it work under Linux with the space bar that said !

[alosec]

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.

[TacticalCoder]

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.

No: if you press down space and then release it, it does a space.

But if you press down space and then another key before releasing space, then space act as a modifier.

The downside is that you don't see your space until you've released it which may be a problem for some. Another tiny issue is that the space isn't "repeating": if you let your thumb on space, nothing will happen. space+b is simply there in case you miss the "repeating space" functionality.

[Daniel Beardsmore]

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?

[spiceBar]

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?

Aha! Naturally you know that I thought about it, right?

Actually I must be honest: dual-role modifiers (in this case space), have been invented and developed by other people who already thought about this. I have just used their ideas, and amongst them was the timeout idea.

Yes, SpaceFN uses a timeout of about 1/3 of a second (300ms actually).

It's short but works great. When I change my mind, generally the 300ms have already elapsed, so I just release space and do something else. When you really type a space, you press it for much less than 1/3 of a second, so there is never any confusion. I have been using SpaceFN exclusively for 3 weeks now, and if it did not work as well or better than dedicated arrow keys, I would have given up on it long ago.

Hasu's firmware can manage all of this. His firmware can be used in the GH60 and in custom-made boards. It can also be used in the HHKB: by replacing the HHKB's internal controller by Hasu's HHKB controller, you can turn it into a fully programmable keyboard. You can reprogram it to act... as an HHKB (!) or to use the SpaceFN layout for example. That's how I'm going to use SpaceFN as soon as I receive the HHKB.

Hasu also has a wonderful small adapter that allows you to turn any PS/2 compatible keyboard (the Poker X for example) into a fully programmable keyboard, on which you can use the SpaceFN layout (or any other layout). I'm going to test this very soon.

[Pacifist]

Only problem I see is accidentally activating a macro in the middle of typing or gaming

[spiceBar]

Only problem I see is accidentally activating a macro in the middle of typing or gaming

When gaming, the fact that the space character is generated when the space bar is released will be a problem. For this reason a keyboard with the SpaceFN layout should have a mean to temporarily switch to another mode where for example CapsLock would be the key to access the Fn layer. In this mode, space would act exactly as it does on a standard keyboard.

When typing, it does not happen. No accidental activating of a navigation or function key. There are safeguards in place.

But you don't have to believe me. Maybe you could try the SpaceFN layout yourself? If you have a Mac or a Windows machine, you can test it right now. You will find how in my OP.

[Daniel Beardsmore]

Maybe you've finally found a use for the scroll lock key/LED

[bubchi89]

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?

I didn't read the posts too carefully but there isn't really the equivalent of home/end in vim because vim bindings aren't a remapping of keyboard keys... they're bindings for a new set of commands. hjkl aren't "arrow keys"; they are "move one character to the left, move one line down, ...". It's a small semantic difference. Anyways here are the defaults:

gg moves you to the top of a file
G moves you to the bottom of a file
^ moves you to the start of a line
$ moves you to the end of a line
w moves you one 'word' forward
W moves you one 'WORD' forward
b moves you one 'word' backward
B moves you one 'WORD' backward
Ctrl-d is sort of similar to page down
Ctrl-u is sort of similar to page up
H moves you to the top of the window
L moves you to the bottom of the window

and of course there are like 30 other shortcuts for navigating a file in vim, but i would say those are the main ones (in addition to hjkl of course)

[TacticalCoder]

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
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.

[spiceBar]

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
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.

I'm not sure you have read my OP thoroughly. In order to avoid the problem you have experienced, there are safeguards in place in the existing implementations.

Even if I did not mention this clearly enough, please remember that I have been using SpaceFN on my main computer for 3 weeks now. How could I possibly tolerate the problem you are mentioning?

I'm aware of xcape, and I have looked at it for the implementation of SpaceFN on Linux (I have 2 Linux boxes sitting near me, so you bet I want a solution for Linux).

However xcape is not adapted to SpaceFN. xcape does not take into account "rollover".

Here is a "graphic" of what I mean by rollover:
space  ----------------------------
other               ----------------------------------

Time goes from left to right. The first line corresponds to the space bar. The second one to another key (let's say J for example).

What you see here is space is pressed and hold, then another key is pressed and hold, then space is released, then the other key is released.

What I understand is that xcape is going to produce an output on the second event (when the other key is pressed). It knows that space is pressed, so the other key is interpreted as a use of the Fn layer => FAIL!

The existing implementations of SpaceFN do not do that. They correctly understand that it is space FOLLOWED BY the other key in sequence, even if the second one "rolls over" the first.

Hasu's firmware implementation has very good rollover detection. The Mac implementation also has a safeguard for this. Lydell's AHK script also knows how to take care of it.

So I think that an idea for a Linux implementation would be to take xcape as a start and rewrite specific parts to manage rollover correctly. I don't know if it would be enough however, because Linux' keyboard management is not intended to remap a key to another one SOMETIMES. 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.

To the best of my knowledge, there is at this time no utility, even used in combination with the built-in Linux keyboard managers, that could be used to implement SpaceFN on Linux.

[TacticalCoder]

Remapping a key permanently is easy (xmodmap or console-setup).

Indeed. I use xkb to do it.

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.

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" 

Peace.

[spiceBar]

Remapping a key permanently is easy (xmodmap or console-setup).

Indeed. I use xkb to do it.

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.

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" 

Peace.

The Linux implementation requires coding a special utility. The utility could then be used beyond the SpaceFN layout to do other stuff.

But the perfect solution is to have SpaceFN managed by the keyboard itself, so the OS doesn't even know you are using it.

This can be done either with a programmable controller inside the keyboard (this already exists, for example SpaceFN can be done on the GH60 or on the Ergodox), or a dedicated controller (if some mass produced keyboard with SpaceFN see the light some day).

It is also possible to use SpaceFN on any PS/2 keyboard or any USB keyboard that is compatible with PS/2 (you know, the kind of USB keyboard on which you can attach the small passive adapter and then plug it on a PS/2 port). This requires a small converter that Hasu has designed. It basically turns your standard keyboard (PS/2 or USB) into a programmable USB keyboard, and you can program the small adapter to use the SpaceFN layout. In this case the perfect keyboard may be the Poker X or the HHKB.

The funny thing is that the Poker is the lowest quality keyboard in my collection. However I keep using it because it's so convenient to use with SpaceFN.

[utku]

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.

2. save following as spacefn.xmodmap

Code: [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]

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.

2. save following as spacefn.xmodmap

Code: [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.

Well, first thank you for helping with SpaceFN and Linux.

I'm afraid that your solution still does not take rollover into account. I have explained the problem in one of my previous posts. As TacticalCoder pointed out, when you type fast the rollover problem is going to kick in, and some of your spaces are going to accidentally generate SpaceFN combinations. NOTE: the rollover problem is already solved in the Mac and Windows implementations of SpaceFN, as well as in firmwares that implement SpaceFN.

Also, I think that turning space into AltGr is not going to work.

I'm using a European layout (french AZERTY), and on this layout the AltGr key (right Alt) is used to generate many characters on the top row. For example the following characters:
  ~ # { [ | `\ ^@ ] }
are all generated with AltGr + a key on the top row.

In SpaceFN, space in combination with a key on the top row should generate the F1..F12 function keys.

On top of this, even on a QWERTY keyboard, right Alt + digit (from the top row) is a valid shortcut for many applications. SpaceFN, correctly implemented, does not disable these shortcuts.

I still believe we need a dedicated utility for Linux because, as I said before, the standard Linux keyboard manager, even with xcape, is not flexible enough to implement SpaceFN.

[utku]

@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.

[spiceBar]

@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?