geekhack

geekhack Community => Keyboards => Topic started by: spiceBar on Sun, 17 November 2013, 13:36:43

Title: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sun, 17 November 2013, 13:36:43
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):

[attachimg=1]


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:

[attachimg=2]


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

[attachimg=3]


And its Fn layer:

[attachimg=4]


(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>
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: stancato9 on Sun, 17 November 2013, 13:40:01
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. :thumb:
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: tbc on Sun, 17 November 2013, 14:05:45
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sun, 17 November 2013, 14:48:53
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. :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: dante on Sun, 17 November 2013, 15:12:15
This is absolutely brilliant.  Once seen it can't be unseen!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Puddsy on Sun, 17 November 2013, 15:14:23
And this is why I love the miniLA

It's kinda like this but with actual arrow keys
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: dorkvader on Sun, 17 November 2013, 15:14:38
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jeffgran on Sun, 17 November 2013, 15:34:04
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sun, 17 November 2013, 15:42:54
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: durandalx on Sun, 17 November 2013, 21:22:59
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sun, 17 November 2013, 22:48:22
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: tbc on Sun, 17 November 2013, 22:55:00
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: kenmai9 on Mon, 18 November 2013, 03:08:39
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 18 November 2013, 11:12:38
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: lydell on Mon, 18 November 2013, 14:22:07
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 18 November 2013, 14:45:49
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Findecanor on Mon, 18 November 2013, 18:01:24
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 18 November 2013, 18:11:11
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: kenmai9 on Mon, 18 November 2013, 18:57:29
G for end and Y for home?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: JayG30 on Mon, 18 November 2013, 21:31:35
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Matias on Tue, 19 November 2013, 03:32:16
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...


[attachimg=1]
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Air tree on Tue, 19 November 2013, 04:36:37
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: terran5992 on Tue, 19 November 2013, 04:52:46
Might not work for FPS gamers. Cuz you have to jump and maybe switch weapons at the same time
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Tue, 19 November 2013, 07:58:02
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 19 November 2013, 18:12:27
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:

[attachimg=1]


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

[attachimg=2]


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

[attachimg=3]


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.

[attachimg=4]


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.

[attachimg=5]


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:

[attachimg=6]
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: lydell on Wed, 20 November 2013, 10:46:22
A few things I noticed:

Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 20 November 2013, 10:48:34
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).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 20 November 2013, 11:01:51
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Matias on Wed, 20 November 2013, 13:42:45
  • 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.

Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Thu, 21 November 2013, 08:09:31
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
};
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spdx on Mon, 25 November 2013, 14:37:14
Thanks for sharing.  This is a great idea for a 60% keyboard.  :thumb:
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: TacticalCoder on Mon, 25 November 2013, 18:53:17
- 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)
 
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 26 November 2013, 06:59:35
- 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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: TacticalCoder on Tue, 26 November 2013, 07:46:02
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}  :D

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 !


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: alosec on Tue, 26 November 2013, 07:52:47
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: TacticalCoder on Tue, 26 November 2013, 09:07:02
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Daniel Beardsmore on Tue, 26 November 2013, 18:15:33
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 26 November 2013, 18:44:06
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Pacifist on Tue, 26 November 2013, 18:46:29
Only problem I see is accidentally activating a macro in the middle of typing or gaming
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 26 November 2013, 18:57:52
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Daniel Beardsmore on Wed, 27 November 2013, 02:46:24
Maybe you've finally found a use for the scroll lock key/LED :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: bubchi89 on Wed, 27 November 2013, 03:06:19
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)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: TacticalCoder on Wed, 27 November 2013, 06:10:09
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 27 November 2013, 11:24:20
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.

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: TacticalCoder on Wed, 27 November 2013, 17:06:36
Remapping a key permanently is easy (xmodmap or console-setup).

Indeed. I use xkb to do it.

Quote
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"  :o

Peace.

Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 27 November 2013, 20:09:40
Remapping a key permanently is easy (xmodmap or console-setup).

Indeed. I use xkb to do it.

Quote
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"  :o

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. :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: utku on Thu, 28 November 2013, 20:19:19
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.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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 29 November 2013, 05:37:55
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.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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: utku on Fri, 29 November 2013, 10:06:29
@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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 29 November 2013, 12:21:45
@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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: utku on Fri, 29 November 2013, 15:09:52
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.


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 29 November 2013, 15:36:32
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: utku on Fri, 29 November 2013, 15:51:57
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 29 November 2013, 19:41:51
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.
Title: SpaceFN vs. CapsLockFN+EnterFN
Post by: Matias on Fri, 29 November 2013, 22:51:20
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...  :-)

Title: Re: SpaceFN vs. CapsLockFN+EnterFN
Post by: spiceBar on Sat, 30 November 2013, 02:18:47
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...  :-)

How far did you go in your attempts to eliminate the rollover problem?

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? ;-)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Matias on Sat, 30 November 2013, 05:26:12

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.


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: lydell on Sat, 30 November 2013, 06:07:45
I'm slowly moving from Windows to Linux. I'm very much interested in a Linux software solution, since I'm afraid of bricking my keyboard if I start messing with firmware. I use a TECK, and tmk doesn't work with it, right? So either case something needs to be programmed.

I'm currently working on finishing all test cases for dual (https://github.com/lydell/dual). Then I have loads of documentation, tests and algorithms to get started with for a Linux solution. In the best of worlds I want the Linux utility to only deal with dual-role keys, without interfering with standard keyboard remapping utilities—that's xmodmap, right?

The problem is that I'm completely new to Linux. What programming language should be used? C? What APIs will the utility be using? Linux kernel APIs? The X Window System APIs? Where will the implementation work? All Linux distros? Some—those with [insert-appropriate-thing-here]? I'm switching to Trisquel (http://trisquel.info/), so it has to work there.

I have time and will to implement a Linux solution. And I have loads of experience from developing dual. But I don't know much about Linux. However, I'm willing to learn loads about it. Learning a new programming language is no problem either. (Actually, dual is my first AutoHotkey script ever, so I've already been through that.)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jorgenslee on Sat, 30 November 2013, 12:20:04
Wow, this is pretty cool, I am actually using it right now and adapting to it. One thing I have issue with is that I have setup KeyRemap4Mapbook to use f7,f8,f9 as media keys, prev,play,next. When SpaceFN is activated, It doesn't work anymore. Is there a workaround for this?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sat, 30 November 2013, 14:01:48

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.

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.


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

But this implementation is clearly not optimal anyway. That's not how I would do it in a keyboard controller.

Hasu has done a great job on this problem is his controller firmware already.

It may be noted that what's important is the keyboard+user system, not the keyboard alone. By this I mean that both can adapt to each other.

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.



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

Yes, in SpaceFN I think that an alternate mode is needed, one in which space really acts as usual. In can be useful for example if you want to play a game for a while. The gaming mode would restore the normal behavior of space and turn CapsLock into the Fn key.


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

The way I see it, space is a more risky choice for an Fn key, but is so valuable that it justifies trying harder to develop a more complex firmware/driver to correctly manage it.



Quote
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Soarer on Sat, 30 November 2013, 15:11:24
I've shied away from implementing any dual-role stuff in my firmware, because it just seems too hard to get truly 'right', likely impossible. Anything involving a timer/timeout seems wrong to me.

For dedicated Fn keys, I quite like the extra key on ISO layout next to left shift, and the corresponding key on the right (forward slash). They sit under my pinkies quite naturally, and are symmetrical (on a staggered layout anyway). And there's relatively few complications in the software with dedicated keys - the only one really being when the Fn key is lifted before the layered key (just have to remember which layer was active when each key was pressed).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: utku on Sat, 30 November 2013, 17:55:05
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sat, 30 November 2013, 19:22:47
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.

Aha! Welcome on board, Utku! :)

I have been using SpaceFN for more than 3 weeks now, and today for the first time I have used a standard layout again (on a TKL, a Realforce). Just for a while.

It felt really akward. Reaching for the navigation keys it what feels awkward to me now. Can you believe it? But I still can do it very easily. My muscle memory is not messed up, so it looks like I can easily switch from a standard layout to SpaceFN and back. I will confirm this in a few weeks.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sat, 30 November 2013, 23:21:35
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sat, 30 November 2013, 23:55:48
This is a great idea. But I wonder what would be a good solution for those cases when you need to use a 2 keys combo with arrows, that will require three keys pressed at once. For example when navigating an Excel spread-sheet. I think this may be a little cumbersome.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: utku on Sun, 01 December 2013, 01:09:51
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.

definitely possible with xcape + heuristic hacks + xmodmap. otoh i'm trying to eliminate xmodmap from that equation. it's somewhat cumbersome and deprecated.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Matias on Sun, 01 December 2013, 02:32:15
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.

Computer chess would certainly fall into the category of a complicated problem.  :)



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.

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.



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.

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.



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.

Yes, that pretty much sums it up.

Of course, if it's at the point where it's useful to you, it doesn't matter so much if it's not widely adopted.  Formula 1 drivers are not concerned that working moms drive slower cars.

Moreover, they want to be driving the fastest car, and want everybody else to be slower.



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.

To that list, I would also add that it does not have to be perfect to be useful.  Good enough may be good enough.



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.



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.

Yes, it may very well be that.  It would explain some of the more bizarre keyboards I've seen.  :)


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: davkol on Sun, 01 December 2013, 04:22:39
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)

I wish the layouts were symmetrical. Something like what I've done with the ergodox: all modifiers and nav clusters on both halves of the keyboard.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sun, 01 December 2013, 13:41:59


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.

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.



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

Yes, absolutely.

When things get too complicated, it's time to question the approach.


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

That's a very interesting point. You are right.

Given that you have several ways to solve a human interface problem, there will probably be one that people will get more easily. Maybe the simple one, maybe the smart one, and often you don't know which one until you put it to the test.

For this reason, I would really like more people to test our current simulations of SpaceFN. I can take it if people say they don't like it, it already happened for a layout I have suggested some time ago. But being left wondering if I should go further with the design, by lack of feedback, is worse. Fortunately, so far the reactions have been mostly positive.

And about predictability: if the system evolves slowly enough, the user will not perceive unpredictability. Slowly enough for a keyboard may mean several minutes. Well, I don't know yet. But some of the heuristics I'm thinking about work by collecting statistics on the keyboard usage and adapt to the user. So they are not instant changes to the behavior. They are also supposed to be slight changes to a basic system that is supposed to work rather well as is.

What I think is that "New! This keyboard adjusts to your personal typing habits!" would be a cool thing to write on a box. :)

(Disclaimer: I'm not selling nor planning to sell keyboards! :) )



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

Most definitely.

Producing goods without taking into account as much feedback from users as possible sounds like a process from the beginning of the industrial era.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spremino on Mon, 02 December 2013, 13:46:31
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 02 December 2013, 14:34:35
Other cons:
- key chords are awkward, e.g. Control+Left to skip words, Shift+Control+Left to select words.

You'd be surprised. They are not.

After a while you forget about the thumb. You know you want an arrow, the thumb does its job and you don't even have to think about it.

I'm a developer and I've been using this for almost a month now. I do these chords all the time. Ctrl-Home and Ctrl-End also.

You need to try it for a while to believe it.


Quote
- keeping the space bar pressed to move around documents can be tiring, more so on keyboards with harder keys.

Correct. On the Poker I have reds so it's not a problem. On the Realforce I have removed the spring under the space bar.

On both keyboards I have flipped the space bar. I did not like it before trying SpaceFN. Now it makes perfect sense.


Quote
- no number pad layer.

It's designed for a 60% keyboard. When you use a 60% you know you don't have the number pad anyway. That's the deal with TKL and 60%.


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

I map PrtSc, ScrLk and Pause to Mute, Vol- and Vol+, so yes I use these keys, and yes it works well with SpaceFN. You can type these keys with just the right hand and without leaving the home row.

I have accumulated more than 20 years of PC keyboard usage. I spend my days editing source code. So you would think I'm the worse demographics for a 60% and SpaceFN.

But I have found out after trying it for a significant time that it is easy to adjust to SpaceFN. More, the layout of the navigation keys is different enough from a standard keyboard that it does not mess with your existing muscle memory. After using it exclusively for several weeks, I have found that I was able to go back to a standard (full or TKL) keyboard and I did not have any problem. Back to SpaceFN, no problem either.

I understand your concerns, but if you try the layout you may find out that it works better than you expect.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spremino on Tue, 03 December 2013, 08:50:42
SpiceBar, thank you for your reasoned reply. As a former developer myself, I believe that your layout must deliver when navigating code, otherwise you wouldn't be using it. I myself avoid chords as much as I can, hence I'd rather go for a layout with separate keys, hence my dislike for 60% layouts.

Cheers.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spremino on Fri, 06 December 2013, 09:18:03
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 06 December 2013, 16:51:30
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.

Yes, that's what I have found out too, much to my surprise.

The primary motivation to find a usable 60% layout was, for me, the need to reduce hand travel from the keyboard to the mouse, and the ability to center the keyboard in front of the screen.

This alone is a significant gain.

I have two KBT Pure Pro, and they are 60% boards with dedicated arrow keys (very similar to the Minila). They provide the gain of less hand travel without forcing to chord to get simple actions like cursor movement (arrows).

I have found that I like the SpaceFN layout even better because I can keep my hands on the home row to get the arrows from there. It comes at the cost of chording, but chording with the thumb is easy, especially because your thumb is already on the key. It is always on the space key! You don't have to aim for a special Fn key or make any effort to curb your thumb, so chording becomes very natural.

Now my right hand moves very little, because all the navigation keys are already under my fingers. This is so comfortable that it overshadows the cost of having to chord with the thumb.

It is especially noticeable when you switch back to a TKL after using SpaceFN for a while. Reaching for the navigation cluster, all these hands movements... It feels really awkward.

People have been using dual role modifiers, including space, for a long time. Space has often been used as a Shift key, so pressing and holding space and a letter gives the uppercase version of the letter. The left and right Shifts have been used to generate left and right parenthesis when pressed briefly. Ctrl has been used to generate Esc in the same way. Hasu has been using slash (IIRC) as an Fn key to get the arrows.

It's an old idea. Using space as an Fn key to get the cursor movement actions and the function keys was not needed in the past because keyboards had dedicated keys for these actions (and even farther in the past under Unix people used Ctrl to do that). Now that 60% are becoming popular and that keyboard software or firmware can be made smarter, space as the universal Fn key is worth investigating and trying.

It's not hard to adapt to, and there is a real gain.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jeffgran on Tue, 10 December 2013, 22:07:57
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 11 December 2013, 00:03:45
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 have Hasu's firmware installed in an HHKB and in a Cherry MX board. The firmware implements SpaceFN (Hasu did it himself).

I have not noticed any problem. I have tried to fault the firmware, but honestly it performs amazingly well.

Do you have to hold space longer when you want to type a space or when you use it as a modifier?

I don't know if your problem comes from your typing speed or if there is something else. Maybe you could talk with Hasu about this?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Fri, 13 December 2013, 10:07:35
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:
[attachimg=1]
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 13 December 2013, 14:57:29
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Fri, 13 December 2013, 18:17:41
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...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 13 December 2013, 20:32:03
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!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Fri, 13 December 2013, 23:19:19
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...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sat, 14 December 2013, 05:42:38
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Sat, 14 December 2013, 09:21:50

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sat, 14 December 2013, 11:07:12

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.

OK. The HID liberation is listed as supported by the TMK firmware.

Hasu has added SpaceFN as a selectable standard layout in his software, so you should not have much problem trying it. It should be a simple matter of compiling it with the right option and loading it on the keyboard.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Sat, 14 December 2013, 12:22:13
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sat, 14 December 2013, 17:41:41
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Sat, 14 December 2013, 18:19:34

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.

No need for copy paste in my fn layer. Much more important to have a numpad only on my left hand so I don't have to remove my right from the mouse.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Sat, 14 December 2013, 19:17:59
converter/hid_liber has no preset SpaceFN layout while tmk_keyboard supports SpaceFN on keyboard/hhkb, keyboard/gh60 and converter/ps2usb. You can define your favorite layout including SpaceFN yourself, of course.

As for dual role key implementation both software and firmware can do same essentially. But software can use a lot of resource; memory, OS state and etc.. meanwhile with firmware  you can use it on any device without installing software; Windows, Mac, Linux, iOS, Android...
I for one haven't tried software implementations yet, but it seems lydell's 'dual'(AHK) and 'At home modifier'(Xorg) support good roll over and can use with SpaceFN layout.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Sat, 14 December 2013, 20:02:53
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).

[attachimg=1]

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...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 16 December 2013, 22:00:22
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Mon, 16 December 2013, 22:32:38

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?

Been busy so I haven't tried.  I know his firmware can do anything I want it to, I just have not had the chance to build my layouts in it yet.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: domoaligato on Wed, 18 December 2013, 23:15:47
this is incredible. thanks!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Thu, 19 December 2013, 05:14:35
this is incredible. thanks!

What is incredible?

PS: I like your signature.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: yasuo on Thu, 19 December 2013, 05:53:13
thanks your inspiring for make BSfn :))
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: domoaligato on Thu, 19 December 2013, 07:45:36
this is incredible. thanks!

What is incredible?

PS: I like your signature.
using the spacebar as fn in tmkfirmware...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Thu, 19 December 2013, 11:24:12
this is incredible. thanks!

What is incredible?

PS: I like your signature.
using the spacebar as fn in tmkfirmware...

Oh, OK. Yes it´s great.

Have you tried it? I'd love to have your feedback about it, positive or negative.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: domoaligato on Thu, 19 December 2013, 12:37:56
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Thu, 19 December 2013, 17:21:15
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.

You did not say which Poker you have, but I think I have the same setup. I have a Poker X (first model) and Hasu's PS/2 to USB converter. The converter implements the SpaceFN layout by reading what the Poker sends, translating it, and sending it to the PC.

The only problem left now is this totally useless Fn key where a useful Alt key should be. So I'm going to open the keyboard, do a little bit of soldering and physically remap the Fn key to the App menu key (another useless key). Then I will reprogram the adapter by remapping the App menu key to the right Alt.

I must admit that I love the Poker (the Poker X, the first one) and its lack of plate. I don't know why, but with the SpaceFN layout it just feels right.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: domoaligato on Mon, 23 December 2013, 15:09:18
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 23 December 2013, 16:24:08
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: domoaligato on Mon, 23 December 2013, 16:57:19
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...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 23 December 2013, 18:25:48
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...

OK, you mean we will be able to design the layout in a web browser and download the hex file or the keymap_*.c file at the end of the process?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: domoaligato on Mon, 23 December 2013, 20:44:12
yes. I want to start with the gh60 because that is all I have to test on. later I can expand to phantom and other stuff.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: yasuo on Tue, 21 January 2014, 09:18:52
I download full now,but stand-alone exe v0.2.1 can't :( i uses win7 but not compatible in written :confused:
so try Zip  files :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: daerid on Tue, 21 January 2014, 11:29:43
asp.net webservice...

Sooo.... Windows or Linux? ASP on Mac/Linux via Mono has been more than viable for several years now.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 25 February 2014, 19:43:09
I just wanted to update this thread with pictures of a real SpaceFN keyboard with dedicated keycaps:

[attachimg=1]

[attachimg=2]

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: riotonthebay on Tue, 25 February 2014, 19:46:36
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.

This is the Right Way to use WASD's custom keycap offering, instead of the unicorn vomit more frequently seen.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: naasfu on Tue, 25 February 2014, 20:04:48
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 25 February 2014, 21:18:39
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'm using KeyRemap4MacBook as this keyboard is connected to a Mac.


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

Yes. SpaceFN is comfortable, you use less energy when editing text, and it's less tiring for your hands and arms muscles.

Every time I go back to using a standard keyboard I can't help but notice how much I need to move my hands to reach the arrows.


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

Yes these are problems with keyboard remapping software. It's not a "clean" solution.

For the HHKB, Hasu has created a specific PCB that replaces the HHKB's controller PCB (inside the HHKB there are 2 PCBs: one for the keyboard matrix, and one for the controller). If you had this PCB and its components already assembled, you could just swap it with your HHKB's controller, no soldering required, and it would turn your HHKB into a fully programmable keyboard (and you would lose the USB hub).


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

Well, I'm not developing a layout for the Poker. I have developed a layout that is similar to SpaceFN but does not use space anymore, and it turns out that it can be programmed on the Poker 2. I started using this new layout on a Poker X and on an HHKB, then I have purchased a Poker 2 to test on it. It works perfectly on the Poker 2.

The motivation for creating this new layout is that using space as the Fn key meets to much psychological resistance. And for some people it really does not work. For example some apps require that you hold space to do some operations. Obviously this is not compatible with SpaceFN. I wanted to see if it was possible to retain some of the advantage of SpaceFN while at the same time eliminating these objections, and I think I have something interesting now.

I have actually already ordered a set of keycaps for this new layout because at this point I have been using it for more than one month and I believe it is stable. I have tried a number of permutations of keys and I think what I have now is the optimal arrangement, at least for me.


Quote
p.s.  Where is your red TEX case?  :p

In its box. I need to put the red case on the Poker 2 above. The blue case will go to the GH60. I think I'm going to wait for the new keycaps to do that.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: lydell on Tue, 08 April 2014, 12:52:29
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.

I’ve never used Remote Desktop, so unfortunately I cannot help.

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.

Modifiers that stick is a known problem. This is how I used to deal with that problem. I followed the steps in order until something worked:

1. Avoid situations that _always_ cause problems. This meant the “Unlock KeePass” shortcut and elevated command prompts for me. If a modifier still got stuck:
2. Press the `dual.reset()` (https://github.com/lydell/dual#dualreset) shortcut. (Note: There is no such shortcut by default in spacefn-win; I advise you to add one.)
3. Kill the AHK script, then press each modifier once.
4. Log in and out or reboot :(

I’ve really tried to get to the bottom with this problem, but I haven’t been able to fix it totally. These days I’m not using Windows anymore, though, so don’t expect any progress. The AHK implementation is great for trying the layout out, and in my opinion it works quite well most of the time (at least it did for me). But as SpiceBar says, it is not a clean solution.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: admiralvorian on Tue, 08 April 2014, 19:12:21
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: berserkfan on Wed, 09 April 2014, 00:15:50
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

Just a general note from my experiences.

I am a big user of buckling springs and clears, so I am used to heavy springs. But when I tried using a cherry browns function key for a sustained period (holding it down to trigger my numpad layer created by autohotkey), I found it exhausting. And I was using a thumb used to heavier springs such as grays!

It looks like a sticky numlock works better if you need sustained used of the fn layer.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Wed, 09 April 2014, 08:47:26
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 09 April 2014, 21:18:12
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.

By "real", I meant a keyboard with custom keycaps, so the SpaceFN layout is clearly visible on it.

The keyboard pictured does not even implement SpaceFN in hardware.  ;D

I have however at least 2 keyboards that implement SpaceFN in hardware, an HHKB and a GH60, and for them the dedicated keycaps make a lot of sense. Unfortunately, only the GH60 can use them.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: batfink on Sun, 11 May 2014, 08:30:30
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 12 May 2014, 04:29:30
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?

This layout that I have also created and tested for a long time (still using it at this time) uses the right hand thumb to activate navigation keys:
  http://geekhack.org/index.php?topic=57723.0;topicseen

It is the brother of the SpaceFN layout.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: p3lim on Tue, 20 May 2014, 20:05:23
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 than what I am used to expect.
Really like how easy it is to use the FN layer though.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 21 May 2014, 01:07:39
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.

Nice job!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Flamingchook on Mon, 02 June 2014, 20:36:28
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. :))
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 02 June 2014, 21:48:50
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. :))

Great.

Stay tuned, because I'm working on a slight improvement of SpaceFN based on my work on GuiFN.

The changes will be made available as a tmk firmware source code for the GH60 and other keyboards.

Don't worry, the changes are minor.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: quadibloc on Mon, 02 June 2014, 22:06:16
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 03 June 2014, 13:45:16
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 think I had already seen your page some time ago, when I was doing research on keyboard layouts.

I'm not going to comment on all of your designs, as some are not relevant in the current context.

However one thing I have found with experience is that there is one finger that is not well suited for the Fn key, and one that is really a good choice.

The pinky should not be used for the Fn key. It's a weak finger that has very little mobility. While it may not be immediately noticeable, after a long work session it becomes obvious.

But there is one finger that is vastly underutilized and that is very well suited for the Fn key: it's the thumb. Depending on where you decide to put the arrow keys (these are the most used keys in the Fn layout in the context of a 60% keyboard), your thumb will already, naturally, fall on some key. This key is the best candidate for the Fn key.

If you put the arrows on IJKL or HJKL, as I did for SpaceFN, your thumb is already on Space. It becomes second nature to push on the thumb when you decide you want to navigate with the arrows. It's a no-brainer. You don't have to think about the location of the Fn key or reach for it with a weak finger.

The intriguing question was to find out is using Space as a Fn key would work or not. After months of using it, I can tell you it works very, very well.

If you are worried about using Space as the Fn key (which is a legitimate worry: for some applications overloading space is not an option), I have designed another layout called GuiFN that has the arrow keys located further on the right side so the thumb does not fall on Space this time.
  http://geekhack.org/index.php?topic=57723.msg1313182#msg1313182
This layout also works very well (I have also been using it for months: I eat my own dog food).

I know you love to design layouts yourself, so I thought you would also be interested by this one.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: quadibloc on Tue, 03 June 2014, 14:00:37
I have designed another layout called GuiFN
On 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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 03 June 2014, 17:59:36
I have designed another layout called GuiFN
On 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.

It's important to note that GuiFN has not been designed with the Poker 2 in mind. It just happens to be compatible with it, and that's something I noticed well after designing it. I have purchased a Poker 2 one month after designing GuiFN and starting testing it on 3 other 60% boards.

Using the Fn key with the thumb is my design choice. It comes from my experience with SpaceFN, which helped me realize that pressing a Fn key with the thumb while the other fingers were on an inverted T arrow cluster was quite natural and easy to learn. If your pinky is pressing on a key, your other fingers have much less freedom, in particular for the kind of movements that we usually do when we use the arrow cluster.

The main goal of SpaceFN and GuiFN has never been to minimize hand travel. The goal was just to allow a 60% board to be as useable as a TKL. But if you consider hand travel, both SpaceFN and GuiFN end up being more efficient than a TKL or a standard full keyboard!

SpaceFN is the most efficient, as your hands almost don't move from the home position.

GuiFN has been created to answer to the objection of using space as a Fn key while keeping most of the advantages of SpaceFN, and it still manages to be more efficient than a standard keyboard, from the point of view of minimizing hand travel. If optimizing hand travel more comes at the cost of using the pinky, I prefer to keep on using the thumb and I give up on hand travel.


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

With SpaceFN, obviously, you just need one Fn key.

With GuiFN, as you have probably noticed, all the secondary functions have been kept, as much as possible, on the right side. All these can be accessed with the right hand only, with the exception of the F1 to F6 keys and CapsLock.

I understand that you have an interest in designing layouts with the best possible arrangement, in absolute terms, and it's a very interesting process. You can just start with a clean slate and be as creative as you want.

I had to work with more stringent constraints: I start from an existing 60% layout where the number and sizes of the keys are already fixed. I try to leave the main layout as standard as possible, taking into account that many people (including me) already have muscle memory for all the characters-generating keys and most of the modifiers.

When you take this into account, it's already a little miracle to be able to come up with something that works. And that does not leave much freedom for an additional Fn key on the other side of the keyboard. :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Eszett on Wed, 02 July 2014, 22:00:37
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.

“ReturnShift” is the most reasonably solution in my opinion, because:
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.



Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Wed, 02 July 2014, 22:07:10
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...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Eszett on Wed, 02 July 2014, 22:27:38
... 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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: swill on Wed, 02 July 2014, 22:50:35
... 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?

I think it depends how you use shift. I almost always use shift in combination with my arrow keys for highlighting sections of code, so for me that has to be one of the most natural things.

If it is only the space key that autorepeat is hard with SpaceFn, I would have no problem using something like my right alt and space to act as my repeating space. Thats just me though.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Justintoxicated on Wed, 02 July 2014, 23:28:19
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 :(
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Wed, 02 July 2014, 23:34:19
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.0


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.

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 02 July 2014, 23:50:22
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...

You are trying to find solutions for a problem that is already solved in SpaceFN. :)

1. Fn-B  ("Blank") does space. It autorepeats. This works in all implementations of SpaceFN.

2. Double-tapping space is also an autorepeating space, but it works only if you are using the SpaceFN version of TMK firmware.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 02 July 2014, 23:57:03
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 :(

I can confirm that with SpaceFN you don't leave the home row and that using the arrows is much less tiring than on a standard or TKL keyboard. It's one of the things that shocked me the most after using SpaceFN exclusively for three months when I returned on a TKL. I suddenly realized that on a standard keyboard I had to move my hands all around when switching from typing to selecting, and the additional expense of energy was suddenly obvious.

The funny thing is that SpaceFN had not been designed to minimize hand travel. But it just does.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Thu, 03 July 2014, 00:09:39
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.0


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.

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.

The real surprise, when I first tried SpaceFN implemented in your firmware, is that I almost never have a problem with space being misinterpreted. And I did not try to optimize any setting. I just did not have to.

I think that for most people SpaceFN just works. It may be unsuitable for some for other reasons, but not because space is going to be misinterpreted, at least not until your reach speeds above 100-120 WPM.

I have not been able to try the AHK script, because I don't have any Windows computer. On the other hand the KeyRemap4MacBook script never makes any mistake, because it has a rather long timeout. The downside is that you need to press and hold space for a split of a second before you can use the Fn layer. But while typing text, as fast as you want, it cannot trigger a Fn action. It's the opposite actually: you would have to type extremely slowly and leave your thumb on space for too long to trigger an unwanted Fn action.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: davkol on Thu, 03 July 2014, 02:46:48
“ReturnShift” is the most reasonably solution in my opinion, because:
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Thu, 03 July 2014, 03:11:47
“ReturnShift” is the most reasonably solution in my opinion, because:
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.

Yes. People already believe that using space as a dual-role modifier is dangerous, so what are they going to think about Enter!?

I do believe using Enter as a dual-role Shift is dangerous. I would probably avoid using Enter, Backspace or Tab as dual-role modifiers.

Also, Enter is not so easily reachable on ISO keyboards.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Eszett on Thu, 03 July 2014, 12:11:21
Quote
It can be *VERY* dangerous though. Imagine the conversion to Shift fails, when you're doing something in CLI. It can be a disaster.

Do I understand your argument right, you say ShiftReturn increases the chance of
triggering return by mistake (by lax typing), which can be a mess in certain situations?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: scottjad on Tue, 23 September 2014, 23:14:02
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 03 October 2014, 02:34:55
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 know if Hasu could help us with this, but it sure would be nice to have a USB to USB TMK converter. I own several PS/2 to USB converters he has made which are quite useful, but they are a few keyboards they don't work with.

Examples are: the RF87, the Poker 2 and the FC660C. These are USB only keyboards. They are not PS/2 compatible, so the TMK converters do not work with them.

They don't work either with the HHKB, but he has created a dedicated fully programmable replacement controller card for the HHKB that works perfectly. Great work.

A USB to USB converter would be almost universal (it wouldn't work on keyboards that act as USB hubs, and on keyboards that do NKRO over USB, but there aren't too many of them anyway).

I seem to remember I have seen something about USB to USB conversion with the TMK firmware, but it was either not complete or required a different hardware than the one Hasu uses. It was several months ago, so I don't remember clearly what the problem was. I think the USB protocol had to be emulated for one of the USB ports, because the dedicated USB controller was used for the other port, so basically it was a USB software emulation and that was not easy to do and pushed the controller to its limits. The solution is to have a controller or some hardware extension that provides two real hardware USB ports. And the software part to drive the second USB port naturally.

An USB to USB TMK converter would be hot stuff, especially if it's small enough to be hidden inside a keyboard's case.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jacobolus on Fri, 03 October 2014, 02:35:56
Check it out:

https://www.google.com/patents/US6198474
(https://patentimages.storage.googleapis.com/US6198474B1/US06198474-20010306-D00000.png)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 03 October 2014, 03:02:16
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

OK, it looks like I should have read your post more carefully, as you have already found much of the relevant information.

So it looks like a hardware expansion is indeed necessary, in order to add a USB host to the converter. This should take care of the connection between the keyboard and the converter. The converter then uses the build-in USB port to send (and receive) data from the computer.

I cannot say anything about the state of the TMK software in this configuration, except that Hasu says that it is experimental. So it must have some unfixed issues at this time, or it simply has not been tested enough.

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.


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: scottjad on Sun, 05 October 2014, 23:05:31

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 06 October 2014, 02:54:59

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

You did well.

I'm very interested in this USB->USB converter because I own a few PS2->USB ones, which do not work with USB only keyboards. And I would like to convert some of these keyboards to SpaceFN.

I'm the author of SpaceFN and I'm fluent in C, but I do not know the TMK firmware very well. Also, I do not have the required hardware yet (the Arduino and the USB host), and I do not have much time at the moment.

I need to order the hardware and spend some time with it.

Also, we may need Hasu to help us a little bit. If he doesn't read this, I'll send him an email.

I'm not 100% sure, but I think HID mode is enough for SpaceFN. I think the media keys just send scancodes, so HID mode should not be a problem. Mouse mode will probably be a problem.

Now I need a way to get the hardware, which may not be easy as I don't live in the US.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 06 October 2014, 04:55:24
OK, I just ordered the Arduino Leonardo and the USB host shield 2.0.

I guess they will take 7 to 10 days to be delivered. The Arduino will be shipped by Fedex, so I expect it for the end of the week, but the USB host is shipping with AirMail. This will take more time.

When I receive them I try to compile the TMK firmware and the SpaceFN layout for it.

I want SpaceFN to work on this USB->USB "adapter".
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Mon, 06 October 2014, 20:49:46
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 07 October 2014, 05:37:16
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

It's unfortunate that the USB->USB converter uses the legacy notation, because I have recently enhanced the SpaceFN layout to support some goodies from the GuiFN layout, and added optional shortcuts for PgUp and PgDn with the arrow keys (Space-I and Space-J).

But maybe it will not be too hard to adapt to the legacy notation. I'm going to have a good look at it when I receive the hardware.

Yes, maybe it's time to revive the project, because it looks like the hardware needed to make it work is widely available at a reasonable price (even if it's a little bulky at this time), and most keyboards are now giving up on PS/2 support.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: yasuo on Tue, 07 October 2014, 08:00:24
may bad queston
this is effective in ergdox/split keyboard?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 07 October 2014, 08:39:05
may bad queston
this is effective in ergdox/split keyboard?

I don't remember anyone reporting they have tried SpaceFN on an Ergodox.

I think it should work. I can see no reason it would not work. And it would not be hard to do, as the TMK firmware works with the Ergodox.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: argcargv on Tue, 07 October 2014, 10:12:32
I love spaceFN  :thumb:
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: samwisekoi on Tue, 07 October 2014, 10:48:34
[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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 07 October 2014, 11:47:58
[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.

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.


PS: SpaceFN is not reserved to touch-typists. I don't consider myself a touch-typist. SpaceFN has just been designed initially with the goal of being a usable layout for 60% keyboards. It's true that touch-typists may find SpaceFN advantageous, but it's not hard to learn and works for all kinds of people.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: wuqe on Tue, 07 October 2014, 13:27:49
may bad queston
this is effective in ergdox/split keyboard?

Yes, but I prefer to still gave space its own key. I have a Fn key right next to the space, though, so it acts a lot like SpaceFn but doesn't get confused when I'm typing. From left to right, my four 2x buttons are: backspace, shift, Fn, space. Works great!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 27 October 2014, 18:19:12

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.

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.

[attachimg=1]
    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.


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: pharaoh on Tue, 28 October 2014, 13:43:30
Quote
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.


gosh that half keyboard is expensive  :-[  It'd be really fun to try out.


On topic of the SpaceFN, I love it and It'd be neat to have a custom spacebar/fn key
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: wuqe on Wed, 29 October 2014, 12:51:28
...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 something like this in my TMK-powered Ergodox, using the "tap toggle" thing that's already built in. If I tap my Fn key twice, it holds on that layer until I double tap again. (By default, you have to tap five times, which is more foolproof but tough for daily usage.)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Leimi on Sat, 01 November 2014, 15:04:10

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.

This is great news :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: user888 on Wed, 19 November 2014, 13:37:24
I've started experimenting with space-fn on my mac using Karabiner (previousle Keymap for macbook).

I've modified it slightly:

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 19 November 2014, 19:13:10
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.

Did you start from the private.xml I have posted?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: awkorama on Wed, 19 November 2014, 23:57:37
This is exciting. I wanna get myself first mechanical keyboard this christmas and I want it to be a 60%. I was thinking about the layout for too long but now it doesn't even matter, the space key is gonna solve it all. Looking forward to final implementation of USB to USB converter to make this possible.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Wed, 10 December 2014, 13:01:57
I updated TMK USB-USB converter and it supports USB Hub now, so that I can use HHKB pro2 with the converter.
And added SpaceFn keymap, try it.

https://github.com/tmk/tmk_keyboard/commit/a0d6bb1818b90f341b2a5daaea3652fe19cd4184




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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: intelli78 on Wed, 10 December 2014, 13:33:35
I just read about SpaceFN and I like the idea. But like others, I'm having problems with skipped spacebar presses when touch typing. You say that the TMK firmware solves this problem, and I see that hasu has just updated it.

What hardware does one need to use the TMK firmware with an arbitrary keyboard?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Wed, 10 December 2014, 22:13:20
Buying Arduino Leonardo and USB Host Shield 2.0(from Circuit@home) will be the easiest way, you won't need even soldering iron.
Arduino's Shield will also work well but I think Sparkfun's needs to be modified.

https://www.sparkfun.com/products/11286
https://www.circuitsathome.com/products-page/arduino-shields/usb-host-shield-2-0-for-arduino-assembled/
http://arduino.cc/en/Main/ArduinoUSBHostShield
https://www.sparkfun.com/products/9947


Also Pro Micro 3.3V(not Mini) or Teensy with mini host shield will work with some fixes on signal/power routing.
https://www.circuitsathome.com/products-page/arduino-shields/usb-host-shield-for-arduino-pro-mini
https://www.sparkfun.com/products/12587
https://www.pjrc.com/teensy/td_libs_USBHostShield.html


Note that the converter can host only USB "boot protocol" keyboard(6KRO) and not NKRO, it is possible to support NKRO keyboard but you will need to write HID report parser for that. Every NKRO keyboard can have different HID report and it is difficult to support all kind of NKRO keyboards in the market.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: SeeThruHead on Sun, 04 January 2015, 13:28:17
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.

(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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Nai_Calus on Sun, 04 January 2015, 17:40:22
Huh. Looks neat. I like the original idea, and the split spacebar idea. Put everything together instead of having to move your hands everywhere, except on a more normal keyboard.

...But now I'm starting to wonder if I'm the only person in the world who hits the spacebar with my left thumb. >_>; Looking at these layouts where FN is left, or all the key combos would be two handed, makes me feel like I must be some kind of freak. *eyes shiny spot below V and B* :-[

I guess you'd just have to program that to have those swapped if you're a freak like me. XD
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: SeeThruHead on Sun, 04 January 2015, 17:43:44
Yeah I always hit with my right, but since it's a split spacebar you could map fn to whichever side you want. Obviously wouldn't work for people who alternate with thumb they use to hit spacebar, but I don't know how common that is.

http://www.keyboard-layout-editor.com/#/layouts/b1482f802aefbe751fd8840f18eaad62
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 05 January 2015, 01:40:07
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?

If you start modding the keyboard and add Fn keys, forget about SpaceFN completely.

The basic idea with SpaceFN is to use a standard keyboard. With this constraint, one of the solutions is SpaceFN. Another one is GuiFN, and there may be many more.

If you remove the constraint, I'm pretty sure that there are much better ways to organize the layout. With this I mean that you don't need to start with SpaceFN, and actually you should probably not start with SpaceFN: this will prevent you from finding creative solutions.

So it's fine to imagine what you want, and you are free to start anew.

I'm however wondering if you have actually tried SpaceFN. The space character is generated when you release the space key. It's not a fixed time delay, it's just that the generation of the character is linked to the release of the key, instead of the key press as is done usually.

If you are typing or editing text, this change has absolutely no importance. You type as usual, you do not need to think about it.

The cases for which SpaceFN is not satisfying are:
- Gaming when space must be recorded on the key press. In this case I fear a split space bar may also prove troublesome.
- Apps that use space as a kind of push down button. Inkscape is an example: within Inkscape you can press and hold the spacebar while dragging the document to pan in any direction. With SpaceFN you could press and hold space+B instead. Space+B has been added exactly for this reason. But I understand it may not be convenient.
- If you absolutely need space to autorepeat for any reason. With SpaceFN, space+B or double-tapping the spacebar does that, but it may not be acceptable.

If you are not in one of these cases, you should just try SpaceFN without any preconception and see if it works for you. Sometimes we try to solve problems that we are never going to face.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: SeeThruHead on Mon, 05 January 2015, 06:18:15
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 06 January 2015, 22:18:29
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.

Why don't you just try SpaceFN in software first?

Is there something preventing you to do it?

You seem to have ideas and be willing to experience. Don't just think about these things. You need to try them. It's all about ergonomics and muscle memory: nothing that can be fully understood by just thinking about it.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Wed, 07 January 2015, 00:31:32
I need a bit of help with customizing the SpaceFN script. Can any of you help me out? (spiceBar tried, but couldn't).

Basically, I want to modify the default mapping of SpaceFN, into this:

(https://geekhack.org/index.php?action=dlattach;topic=67243.0;attach=86384;image)

(In this context, S means Shift and C means Ctrl.)

The problems I'm currently having are basically these:

1) While some of my custom mapping is working, there are problems with the ones that uses Ctrl as part of the macro/hotkey combo (the Ctrl part doesn't work, while the Shift part does). I'm not sure why it's not working, and it did work at one point, but then stopped working, and I can't remember if I changed anything to the scrip that would stop it from working.

2) What I managed to turn the CapsLock into Left-Ctrl, I was not able to turn Left-Ctrl into CapsLock. This is a minor annoyance and not important, since I almost never use CapsLock, but it would be nice to understand why it's not working.

This is what I have:

Quote
; 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'm not a programmer so I'm just using educated guesses and trial and error. If any of you can help me, I'd really appreciate it.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: sypl on Sat, 17 January 2015, 21:01:45
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Sat, 17 January 2015, 21:25:21
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've been having the same problem with accidental activation. I'm going to try remapping the Fn key to Alt instead and see how that feels. It's not as comfortable as the spacebar, but accidental activation is the greater evil here. If I had a keyboard with Fn or Alt buttons placed closer into the spacebar, it'll feel more natural, but I don't have any keyboards like that currently--all are pretty standard layouts in terms of spacebar length.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: sypl on Sun, 18 January 2015, 13:01:06
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Sun, 18 January 2015, 14:55:41
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.

Although I favor my right hand, I still want to have two Fn keys, since there are times when one I might be using one hand to hold a drink or a snack or even just scratching my nose or something. The Alt keys are the only ones that don't seem to activate anything really harmful to what you're typing. Possible common activations would be Alt+E for Options, and....wow, I think that's about it. All other common Alt+key combos are non-alphanumeric. The software you use might have its own unique hotkey combos that involve Alt+alphanumeric key though. SpaceFN was created mainly for typing/programming and not for typical computer operations, so I guess if you're using it while not doing actual typing/writing, you could be triggering more stuff you didn't intend. For someone like me who adds a lot more hotkeys to the default SpaceFN layout, I get a lot more accidental triggers too--especially with me left pinkie.

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.

I'm going to keep experimenting with SpaceFN and see if I could get it to fit me like a comfortable glove. If not, I'll have to get one of those fully programmable keyboards with ideal placement of Fn keys (slightly shorter spacebar, and dual Fn keys, one at the C and X area and one at the M and , area).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 19 January 2015, 10:58:43
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Hypersphere on Mon, 19 January 2015, 11:51:59
@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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jacobolus on Mon, 19 January 2015, 16:45:22
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.
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).

Holding space + B + alt + ctrl or similar is going to be a real pain in the ass.

[This can obviously be improved by tweaks to space-FN; it’s not an insurmountable problem.]
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 19 January 2015, 17:04:28
@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.

I own a Matias Laptop Pro (Bluetooth) with Quiet Click switches, and I love them. They achieve what no Cherry MX switch has ever been able to provide, as far as I can tell: a very crisp tactile feedback.

I have heard that the TMK firmware now works with the Infinity keyboard, and the Infinity, in the last Massdrop sale, came with the option of Matias Quiet Click switches.

I'm waiting for a new drop on the Infinity, because I really want one now. It has been requested more than 1500 times, so it's likely to be on Massdrop again, soon. It looks like it is one of the best ways to get a SpaceFN-compatible 60% keyboard (and also compatible with whatever layout you like).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Wed, 21 January 2015, 19:59:15
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?

The Space+B doesn't work with Photoshop. I don't know why. And Photoshop hotkeys cannot be changed AFAIK--only custom actions can have custom hotkeys.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Hypersphere on Wed, 21 January 2015, 20:49:29
I've lost track of how often I hear people say that they can't do this or that with their keyboard because of the key combinations that are needed for Photoshop. It's amazing how much of an impact this program has had on how people use or don't use their keyboards.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jacobolus on Wed, 21 January 2015, 21:54:01
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Thu, 22 January 2015, 15:40:30
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.

Ah, you're right. I had forgotten about the change Adobe made with the CS version. My mind was stuck in the pre-CS days of Photoshop.

Too bad spacebar for the temporary hand tool can't be changed. I've been getting along with the SpaceFN a lot better now that I'm using it more and more, and it would be nice to not have to turn it off whenever I'm in PS (which is often).

I tried to reassign the FN key to Alt instead of spacebar, but it didn't work--the Alt was just triggering whatever hotkeys in whatever software I was using that starts with the Alt key. Not sure why it didn't work.

All I did was change the two instances of "space" in the following to "Alt" instead:

*Space::
*Space UP::dual.combine("F22", A_ThisHotkey, {delay: 150, timeout: 300, doublePress: -1})
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jacobolus on Thu, 22 January 2015, 16:27:49
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Thu, 22 January 2015, 20:07:45
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.

If I get a hardware controller, would it be a fairly simple process each time I swap out a keyboard--just plug the new keyboard into the controller, and then the controller to the computer?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jacobolus on Thu, 22 January 2015, 20:12:41
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Thu, 22 January 2015, 21:34:15
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jacobolus on Thu, 22 January 2015, 22:10:23
If the keyboard supports PS/2, that’s fine. Those passive USB->PS/2 adapters only work if the keyboard supports both USB and PS/2 protocols over the same pins. Not all USB keyboards do though.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sun, 25 January 2015, 10:43:04
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?

Yes, your keyboard must be PS/2 compatible. Many keyboards have a USB plug but are also PS/2 compatible with the help of a passive adapter. Some are not compatible with PS/2, however.

If your keyboard has a PS/2 plug, no problem. It is compatible with Hasu's PS/2->USB adapter.

If your keyboard has a USB plug and, using a passive USB-PS/2 converter, you can plug it in a PS/2 port on your computer and the keyboard works (this requires rebooting the computer), then your keyboard is compatible with PS/2.

In this case, it will work with Hasu's PS/2->USB converter, which also acts as a fully programmable keyboard interface and can turn your keyboard into a real SpaceFN keyboard. Your computer will not even know that your keyboard is a SpaceFN one. It will think it's a standard keyboard. No driver will be required on the computer, so you will be able to plug your keyboard into any computer and use it immediately.

Space-B will act as the spacebar in Photoshop. Holding down space-B will do the same as holding down the space bar on a standard keyboard.

Here is a picture of Hasu's PS/2->USB converter connected to a Poker X keyboard (which has a USB plug but is PS/2 compatible):

[attachimg=1]

You plug it into your computer with a mini-USB cable that plugs into the golden connector on Hasu's converter.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Sun, 25 January 2015, 13:28:44
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 27 January 2015, 20:15:39
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?

The controller is wrapped in a transparent plastic that shrinks when heated. It is sufficiently protected for sedentary use.

It could be put inside any small plastic box, but even better, it could indeed be hidden in the keyboard's case itself.

This requires soldering skills, as you need to desolder the PS/2 connector and solder the pins from there to the keyboard's PCB.

I wanted to do that for the Poker X pictured above, but I have not done it yet.

Apparently the Infinity keyboard is compatible with the TMK firmware, so in my opinion you should get one as soon as it reappears on Massdrop. You will have to program the firmware, which is somehow more complicated than AHK, but it looks like you will find help here. You will have to deal with the TMK firmware anyway: it is one of the most flexible, and it will allow you to program a keyboard exactly as you want it.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jacobolus on Tue, 27 January 2015, 20:56:13
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.)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Wed, 28 January 2015, 01:08:55
Yes, Tmk supports cortex controller with mbed.org HAL layer, yay!
Give hasu a free keyboard if you need tmk port on it!

https://geekhack.org/index.php?topic=41989.msg1586196#msg1586196
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Wed, 28 January 2015, 01:47:43
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: lejboua on Thu, 29 January 2015, 08:02:57
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Thu, 29 January 2015, 10:45:58
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 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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Thu, 29 January 2015, 15:56:05
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.

OMG! That is freaking awesome! Thank you so much for sharing that! It's exactly what I wished AHK could be. It's so much more intuitive and easy to use for someone who is not a programmer--just simple interface for customization. It's not as deep as AHK, but it does almost everything I want (except for Changing the CapsLock to Ctrl, which I'll still run AHK just for that. It also doesn't allow for timing out of the activation key the way SpaceFN does). If it ends up as stable for me as it has been for you, then   :thumb: :-*

If only you had shared this earlier, I wouldn't have spent so many hours trying to learn/troubleshoot AHK and bugging the hell out of spiceBAR and lydell with my endless stream of questions.  ;D

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.

If TouchCursor proves to be stable, then I won't have to go the hardware route (which just adds more complication due having to learn how to use it, program it, etc). TouchCursor is so intuitive and simple and does almost exactly the same thing what you designed SpaceFN to do (great minds think alike, eh?), that it's just a much simply solution for someone like me. If it somehow doesn't work out, then it's time to get a hardware solution.

BTW, I find that sometimes when AHK freaks out, reloading the script takes care of the problem.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Thu, 29 January 2015, 20:10:24
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).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 30 January 2015, 00:46:26
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. :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Fri, 30 January 2015, 14:38:20
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. :)

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 30 January 2015, 17:29:36
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. :)

Well you know, what we call a hardware solution is actually a firmware that we flash to a programmable keyboard.

I have tweaked my version of SpaceFN maybe 20 or 30 times since I have keyboards that can run the TMK firmware.

I know you are not fluent in C, but what you do essentially is edit a table of key names in your favorite text editor in a file called "keymap_spacefn.c".

Then you compile the file by issuing the following command in a terminal (DOS box or whatever they call it now in the Windows world): make KEYMAP=spacefn

And finally you flash the resulting firmware to the keyboard:
- press the small "program" button on the back of the keyboard
- type this command: make dfu

Then you unplug the keyboard, plug it again, and you can test the result.

As you can see it's not much more complicated than editing the AHK script.

Honestly I have skipped a few steps that you do only once, the steps to install the compiler that allows you to create the firmware.

At least with a hardware solution involving TMK, I would have been able to help you. :)

Maybe when you have stabilized your own version of SpaceFN, after testing it for long enough in AHK, I could create a TMK firmware for it. Then it would be quite easy to flash it to a programmable keyboard. If you can get a small PS/2->USB adapter, you could even test it with any PS/2 compatible keyboard, before you decide to purchase a fully programmable one.

I think that if you really like SpaceFN it's the logical, ultimate, no worries solution for you.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: wuqe on Mon, 02 February 2015, 08:34:44
lol SpiceBar, even the hardware is software! I agree completely, though; I tweak my Ergodox firmware at least once a month, whenever I realize some tweak that would make it even awesomer. :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Mon, 02 February 2015, 11:25:39
I've not found and tried this software before. TouchCursor really works well for me as my firmware does. And 'dual role key' is implemented in clean, simple and concise way, really smart and great job! I like his code and you can refer it to implement yourown tool.

TouchCursor doesn't use any timer so you can't 'cancel' your space(dual role key) using timeout and 'double tap repeat' is not available. These won't problems probably in most cases.

spiceBar, please add this tool in first post, it is an good option for Windows users.


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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 02 February 2015, 17:58:30
@Hasu: done!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 02 February 2015, 17:59:53
(deleted)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spdx on Mon, 16 February 2015, 23:43:43
Anyone has lagging issue with TouchCursor?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Tue, 17 February 2015, 01:55:37
Anyone has lagging issue with TouchCursor?

Not on my end (Win 8.1, 64 bit). It is far more stable than AutoHotkey. I did have some issues with it not remembering my custom hotkeys at first, but then the problem went away, so I assume it was due to some other issues I was having with my computer.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: JaydrVernanda on Tue, 17 March 2015, 15:04:09
Thank you SO much for recommending TouchCursor. The SpaceFN AHK script would permanently activate the FN layer sometimes and it drove me nuts.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: mecano on Thu, 09 April 2015, 07:15:05
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 l
Code: [Select]
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.

Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Thu, 09 April 2015, 16:46:04
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 l
Code: [Select]
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.

You are now completely off topic in this thread.

You should start a new thread about VIM if you want to discuss this further.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: mecano on Mon, 13 April 2015, 05:12:06
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 l
Code: [Select]
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.

You are now completely off topic in this thread.

You should start a new thread about VIM if you want to discuss this further.

Am I? Well sorry then.
I am using a space layer since I saw Shane's great Planck video.
Space layer is really great and getting rid of one trick pony keys to combine them with modifiers when possible is even better.
My post was less about vim than remapping already existing solutions in some particular situations but hey whatever.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: FuriousGeorge on Mon, 13 April 2015, 11:52:02
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: mecano on Mon, 13 April 2015, 15:14:16
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?

That's the way I'm heading (hardware) but took the custom build path (I want 13/15 keys per only 4 rows in total).
I am now using a combination of hardware/software (kbt pure pro programmable alternate layer+Karabiner, osx autohotkey equivalent I guess) but it's less than perfect.
To answer to your question, did you look at ctrl-alt and ortholinear web sites ? They provide built solutions and have fully programmable multi layer keyboards.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 14 April 2015, 02:05:49
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:

[attachimg=1]


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).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: FuriousGeorge on Tue, 14 April 2015, 11:38:03
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 14 April 2015, 14:54:32
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.

Really? USB-USB? That's great, I had missed that.

I had purchased an Arduino to do this, but did not find the time to work on it. If Hasu has already built a solution, that's perfect.

Do you have a link? Thank you in advance.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: FuriousGeorge on Tue, 14 April 2015, 15:10:19
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Tue, 14 April 2015, 23:28:20
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.

Thank you for pointing this out.

Yes, it would be perfect. If Hasu doesn't provide SpaceFN out of the box, I'll work on providing it.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Thu, 23 April 2015, 15:43:27
TouchCursor is an awesome piece of software, it is simple, it is effective. Thank you for sharing.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: SeeThruHead on Sat, 25 April 2015, 13:31:50
So I've just received an HHKB and since there is no left control to map to hyper i've had to use spaceFN to map HJKL to the arrow keys.

I'm having some issues with the initial modifier wait and wanted to see if anyone has any ideas on how i can fix this.

I have left and right shifit mapped to left and right parens when pressed alone, but the initial modifer wait is causing those to fire parens whenver I type a shifted character. I tried setting the ms wait down to 0 (and then slowly increased it) but that is causing me to lose a lot of spaces when typing quickly, has anyone else figured out a way to overcome this?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: asgeirtj on Tue, 28 April 2015, 11:40:48
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: FuriousGeorge on Tue, 28 April 2015, 11:47:00
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.

Make sure that you also download Dual. Is should be linked from that same github page. I checked my setup and it looks like there should be a \lib\dual\ folder under the folder where the main script is located. Extract the contents of the dual file to that folder.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Tue, 28 April 2015, 12:28:43
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: FuriousGeorge on Tue, 28 April 2015, 12:41:14
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.

Strongly agree. AHK is much more powerful and configurable, but I had issues with space not working right by itself and with it getting stuck "down" as a modifier. TouchCursor has worked great. It's also much simpler to setup.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: asgeirtj on Tue, 28 April 2015, 14:59:53
Just installed touch cursor, it's amazing, really excited to see if I'll be able to stick to these new changes :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: asgeirtj on Wed, 29 April 2015, 05:18:10
Is it possible to do something similar to this in touchcursor/ahk.  Use capslock as a double key.  If tapped it's backspace.  If it's held its ctrl.

capslock UP:: send {backspace}
Capslock::ctrl

But it's really troublesome for example when i do ctrl+a it also deletes everything :P.  Do i need some latency or something?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Wed, 29 April 2015, 07:11:33
Just installed touch cursor, it's amazing, really excited to see if I'll be able to stick to these new changes :)


Touchcursor is really useful, now I really do not need dedicated arrows. My main restriction was the use of chorded commands in Excel, but with touchcursor it is totally possible.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: pr0ximity on Wed, 29 April 2015, 22:29:40
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).

356 Mini's also  :D this might be a better option than trying to implement SpaceFn through ps2avr on the board itself.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Tue, 05 May 2015, 02:52:45
Looking forward to try it once I received my b.face PCB. :D
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: FuriousGeorge on Fri, 15 May 2015, 16:53:34
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Fri, 15 May 2015, 17:36:55
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Zukoi on Sat, 16 May 2015, 00:03:32
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sat, 16 May 2015, 08:20:56
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.


What do you mean by taping?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Zukoi on Sat, 16 May 2015, 08:24:03
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.


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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sat, 16 May 2015, 09:16:10
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.


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.


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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Zukoi on Sat, 16 May 2015, 10:19:36
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.


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.


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.
It is. Quite a clever design which is why I plan to program my keyboard around it.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sat, 16 May 2015, 14:45:17
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.


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.


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.
It is. Quite a clever design which is why I plan to program my keyboard around it.
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: joric on Sun, 17 May 2015, 19:23:44
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sun, 17 May 2015, 20:28:38
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.


AHK is a general scripting program, that is very good if there is no other option, in this case TC comes handy as it is dedicated for this problem.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: asgeirtj on Wed, 03 June 2015, 21:43:53
Anyone getting this happen:  accidentally hit a space shortcut in normal use?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Wed, 03 June 2015, 22:20:15
Anyone getting this happen:  accidentally hit a space shortcut in normal use?

I find that it almost never happens with the shortcuts I've setup for my right hand, but for my left hand, it happens a lot (I've mapped the various shift-activated selection macros to the left had, to select one word at a time, or one character at a time). What happens is often I'll accidentally select entire sentences or paragraph with the left hand shortcuts and then when I hit enter, they'll get deleted. It's not a huge problem since whenever it happens, I just undo and I'm right back to where I was. It's a little annoying, and I've been thinking I should stop using the left hand shortcuts. As for the right hand shortcuts of just arrow keys, home/end, pg up/down, ctrl+backspace, ctrl+delete, ctrl+arrow keys, etc, they never get activated accidentally.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: gosinger on Mon, 08 June 2015, 19:25:14
Just wired up my first Teensy 2.0 plus hasu's great TMK firmware with space-FN layout, so far I'm pretty happy - great job, for both function, design and implementation to all those involved :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Mon, 08 June 2015, 20:47:18
Anyone getting this happen:  accidentally hit a space shortcut in normal use?


No. It never happens in my case. Actually, I wonder how it could a space shortcut to get activated by accident. Maybe you fingers synchronization is overlapping with thumbs on space bar. I use the right thumb to type space almost always.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: joc on Sat, 13 June 2015, 21:34:43
I'm using a "shift-activated" version of the SpaceFn idea to allow the space bar to function as normally as possible; the space bar activates on press and repeats on hold as usual. With a shift-activated SpaceFn, one shift key needs to be initially held down for the space bar to activate the Fn layer. The Fn layer remains activated as long as the space bar is held down - the initially held down shift key does not need to remain held down for the Fn layer to remain activated. This is how I have it set up:
Base layout:
[attachimg=1]

Fn layout:
[attachimg=2]

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sat, 13 June 2015, 22:35:34
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: joc on Sun, 14 June 2015, 00:00:49
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sun, 14 June 2015, 00:19:09
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.


I can see your point; and, sometimes I also miss the full space bar functionality, however, in my case, the advantages overcome the compromises. I am now using for the very first time a keyboard with no dedicated cursor arrows, without the need to remap some keys to have them in the first layer.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: colomb on Tue, 28 July 2015, 00:37:55
Just a quick word to say thank you for the karabiner script. A coworker introduced me to SpaceFn and I've been eager to try it at home. Luckily I have been using karabiner to remap some other stuff. Now, to dial in the initial modifier wait and the timeout...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: orihalcon on Thu, 30 July 2015, 17:50:37
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: joc on Thu, 30 July 2015, 19:54:58
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.

It's not possible to implement SpaceFn via Soarer's configuration file - it would require a firmware modification and the firmware's not available. This (https://geekhack.org/index.php?topic=51069.msg1139610#msg1139610) is what Soarer had to say about dual-role keys.

As an alternative, I have a modified version of xwhatsit's controller firmware that includes SpaceFn. I can upload it here if you want to try it out.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Thu, 30 July 2015, 23:53:26
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sat, 01 August 2015, 04:38:17
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.


Looking forward to have my custom to put SpaceFn on!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: aklt on Mon, 03 August 2015, 12:30:55
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...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Mon, 03 August 2015, 17:00:11
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Tue, 04 August 2015, 22:30:05
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.

Hardware-based is the best answer. Even if you don't have the ability to swap out PCBs, you can still use a plug-in device such as hasu's TMK-based USB to USB converter (https://geekhack.org/index.php?topic=69169.msg1809853#msg1809853).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: aklt on Wed, 05 August 2015, 09:08:51
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!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Wed, 05 August 2015, 14:15:52
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!

It's an amazing little dongle. Basically turns any keyboard into a fully-programmable one.

The only catch is for boards like the Poker and HHKB, which already have Fn keys, they don't send a scancode when Fn is pressed so you can't redefine them using the converter.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: aklt on Wed, 05 August 2015, 17:57:10
Ah, I see.

My plan is to use this with a Filco keyboard, so I think I will be fine.

Have many of you built one of these?  It would be great to see some pictures of
the various designs, I think ;-)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: wakko on Wed, 05 August 2015, 19:16:23
The USB-USB convertor is legit. Had an arduino board laying around; flashed SpaceFN onto it. Works flawlessly!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Wed, 05 August 2015, 22:16:37
The USB-USB convertor is legit. Had an arduino board laying around; flashed SpaceFN onto it. Works flawlessly!

Nice!

Although, you just had a $30 USB host shield laying around? Weird.
Title: The SpaceFN layout: trying to end keyboard inflation
Post by: wakko on Thu, 06 August 2015, 08:47:45
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:
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Thu, 06 August 2015, 10:19:31
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:

It's not that weird, I guess. I've got a few Arduinos & shields, 2 Raspberry Pi's, a couple of Parallax dev boards, MSP430's, and a bunch of small breakout board kits lying around. You just don't see a ton of that on GH.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sat, 12 September 2015, 23:54:18
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.

Updated with the latest layout. The Space-FN makes this to work like charm.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sun, 13 September 2015, 16:24:22
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sun, 13 September 2015, 18:09:06
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


I also found the arrow keys in FN easier to use than with another FN key in my GON. Maybe is time for GON to include a sort of FN implementation in his software.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: asgeirtj on Thu, 17 September 2015, 07:31:28
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Thu, 17 September 2015, 07:40:38
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Thu, 17 September 2015, 07:46:15
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.

Chorded command: Using more than one key press to invoke some action in a software - this is my potato definition - For example control+shift+down arrow to mark a block of cells in Excel until the last filled cell in a column.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: tominabox1 on Fri, 18 September 2015, 08:21:50
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...
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: geniekid on Fri, 18 September 2015, 08:34:27
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: tominabox1 on Fri, 18 September 2015, 08:39:20
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.

Ah I guess I didnt try to mess with that.  I will read through the thread again and see if I can roll that in.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sun, 20 September 2015, 09:36:44
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: geniekid on Sun, 20 September 2015, 11:31:54
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?

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sun, 20 September 2015, 12:24:42
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?

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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Sun, 20 September 2015, 12:58:03
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?

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sun, 20 September 2015, 14:19:26
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?

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.


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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Sun, 20 September 2015, 14:29:50
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?

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.


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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sun, 20 September 2015, 14:30:19
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?

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.


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.


Ok cool thanks you.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: keshley on Sun, 20 September 2015, 19:17:48
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)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: proselytiser on Mon, 21 September 2015, 09:56:38
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...)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Mon, 21 September 2015, 10:13:05
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...)


Move your command key to the caps lock key cap position. It is way easier that way. :D  Pretty much like the HHKB layout.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Mon, 21 September 2015, 10:14:18
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)


Thanks for the link btw. ;)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: proselytiser on Tue, 22 September 2015, 02:43:06
Found this great GitHub issue on the Karabiner repo (https://github.com/tekezo/Karabiner/issues/229) which has a great solution for the rollover issue in the form of a new-ish setting called __BlockUntilKeyUp__.

Basically means that Space is treated as FN only if the "other" key is pressed after Space goes down and is released before Space goes up; ie:

Code: [Select]
# Yes, this is a FN layer press:
space -------------------------------
other            --------------

# Nope, this is just normal rollover, typical when you type fast
space ------------------
other               ----------------------
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: EvilOlivE on Tue, 29 September 2015, 15:35:14
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 like
Code: [Select]
Send 3dpoly{ENTER}
Or is this limited to only keyboard functions?  Thanks!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Tue, 29 September 2015, 16:27:15
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 like
Code: [Select]
Send 3dpoly{ENTER}
Or is this limited to only keyboard functions?  Thanks!

If you are using AutoHotKey you can program pretty much anything you want. Its specifically design for macro-based automation of repetitive tasks. Check the pre-written examples in the help file.

This  (http://www.autohotkey.com/board/topic/110311-automating-autocad/)is an example of a thread with examples.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: EvilOlivE on Tue, 29 September 2015, 17:54:42
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!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: joc on Tue, 29 September 2015, 19:32:21
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")

Edit: Working solution here. (https://geekhack.org/index.php?topic=51069.msg1887106#msg1887106)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Tue, 29 September 2015, 20:21:50
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ajx on Fri, 02 October 2015, 02:38:51
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
 
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Fri, 02 October 2015, 07:48:42
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: keshley on Fri, 02 October 2015, 08:07:42
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.

Oooh, I like this idea. I'm stealing some of it.  :thumb:
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Fri, 02 October 2015, 08:33:47
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.

Oooh, I like this idea. I'm stealing some of it.  :thumb:
Steal away, that's why I shared it!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: tominabox1 on Fri, 02 October 2015, 10:34:12
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: njbair on Fri, 02 October 2015, 13:08:52
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).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: tominabox1 on Fri, 02 October 2015, 14:34:21
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).

You may be right but I really don't think I hold the space down that long lol.

I will try to use it again... it really is the best place for a fn key I think.  Do you have any suggestions for being faster on the space bar aside from just using it more? I think as my speed improves I might actually have to hit the keys faster and alleviate the problem.

In TMK does the TAPPING_TOGGLE do anything of value here or should I focus on TAPPING_TERM
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Fri, 02 October 2015, 15:14:42
Is Space-FN the best? Well, there is always tolerance for less efficient methods.

 :p :p :p
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ajx on Fri, 02 October 2015, 16:41:35
It cannot be the best for sure due to its own limitations (i.e gaming)
That why i ve added serveral layers of FN but Space as FN is  the one that i find the most ergonomic and efficient
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Sun, 04 October 2015, 16:22:23
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sun, 04 October 2015, 17:22:58
Is Space-FN the best? Well, there is always tolerance for less efficient methods.

 
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)

Do you have other layout to suggest? Or are you just trolling pointlessly?
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.  :p
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Mon, 05 October 2015, 01:38:19
Is Space-FN the best? Well, there is always tolerance for less efficient methods.

 
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)

Do you have other layout to suggest? Or are you just trolling pointlessly?
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?

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Mon, 05 October 2015, 08:27:56
Is Space-FN the best? Well, there is always tolerance for less efficient methods.

 
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)

Do you have other layout to suggest? Or are you just trolling pointlessly?
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)

Oh ok. By less efficient do you mean having Fn on another key or less efficient SpaceFn layout?

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.

It is a simple fact, your thumbs are already over the FN when typing, always; it follows that you can activate any other chorded command with the space bar plus other keys, the more accessible, are, of course, the home row.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: EvilOlivE on Mon, 05 October 2015, 14:03:33
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")

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? 


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, I tried Touch-Cursor too, the gui is nice but not having a timeout is a little bit of a deal breaker for me.  If I hold space, change my mind, then release, it still sends space.  The way I have AutoCAD set up, sending space sends the last run command.  That would get frustrating very quickly since I'm so fickle haha. 
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: joc on Mon, 05 October 2015, 21:02:43
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? 

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: EvilOlivE on Wed, 07 October 2015, 10:48:16
Quote
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.


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!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: joc on Wed, 07 October 2015, 16:07:56
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!

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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: EvilOlivE on Fri, 09 October 2015, 10:35:30
Quote
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.

Interesting.  I was trying to make my own "mode" and add everything within that modes #If.  I noticed the delay you were talking about so I started to play around with the delay option.  I think your script works better.  Thanks again!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sun, 25 October 2015, 14:37:14
Can someone explains the advantages and drawbacks of using AHK scripts against Touch-Coursor?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: g012 on Sat, 28 November 2015, 10:00:53
Hey,

Concerning the rollover detection, has anyone tried considering the duration of the overlap ?
Code: [Select]
  FN  ----------------------
  KEY               ------------------
             x          y        z
Using some user-defined constants DX, DY, and DZ, how about:
Code: [Select]
if (x > DX || y > DY) ismod = true;
if (x + y > DZ && z == 0) cancel = true;

From what I gather, in the current implementation only the part "x > DX" is considered for "ismod". Using this version would allow setting a higher value for DX, reducing the number of mis-fn triggers. After all, the main thing that matters is the duration between the press of the modified key and the release (if any) of space bar (fn).

I point this out also because I would not just put arrows or navigation (vi input is here to do that better), or even worse rather useless media keys in the fn layer, but actual letters (éèà etc.) and programming symbols ([]#{} etc.). So speed matters just as with any regular key. As of now, I'm using a layout with a dead key for that (since the last 12 years or so - and yes, I'm totally anti AltGr, never at the same place on different keyboards, and requiring way too much stress on the thumb to activate it except for a few keyboard designs, mostly ISO - and ANSI is far more ergonomic than ISO for everything else).

Any thoughts on this modification of algo ?

Note that I haven't tried the scripts here yet, so I'm speculating for now.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sat, 28 November 2015, 15:14:42
Can someone explains the advantages and drawbacks of using AHK scripts against Touch-Coursor?


No one?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Lunatique on Sat, 28 November 2015, 16:00:38
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sat, 28 November 2015, 16:46:10
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.


It is similar to my own experience, I have been using AHK for at least 7 years so far; but, even having some skills with it, I do not see any way a auto hot key script may be as efficient as Touch Cursor is.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Phenix on Thu, 07 January 2016, 17:04:19
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Thu, 07 January 2016, 20:35:52
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 have been encouraging people to give Touch Cursor a try, you can set pretty anything you want with it.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Phenix on Thu, 07 January 2016, 20:42:28
so its really not possible!?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Thu, 11 February 2016, 07:21:33
 This is a brief report on the use of the SpaceFN concept: Now I use a 58 keys layout, including the spacebar, with no other Fn key but the space bar on a GON Nerd60. The second layer is accessible by TouchCursor, it allows me to use the same layout on my laptop keyboard. The efficiency is great now. I encourage GH fellows to give SpaceFN a try.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Salt Peanuts on Thu, 17 March 2016, 07:32:48
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: FuriousGeorge on Thu, 17 March 2016, 11:44:11
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Salt Peanuts on Thu, 17 March 2016, 14:23:29
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: FuriousGeorge on Thu, 17 March 2016, 16:35:30
Thanks for the tip.  I'll see how far I'll get with TMK since I have absolutely no coding background.

I'm pretty sure the last time I did any coding was with a 16 bit version of visual basic, but I managed to figure it out eventually. :) Hopefully I can get my frosty flake installed and figured out soon. If I do, I'll let you know what I did.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Salt Peanuts on Fri, 25 March 2016, 06:32:04
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Fri, 25 March 2016, 09:12:08
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Salt Peanuts on Fri, 25 March 2016, 19:13:45
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Fri, 25 March 2016, 19:52:06
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.


That makes sense.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spanyam on Fri, 25 March 2016, 19:54:39
I just tried this out on Karabiner, and I'm not liking the experience of basic typing. The fact that a space only actuates when letting go of the space bar completely messes up my typing memory. I usually do around 120 wpm when not accounting for typos, and a lot of the spaces are getting skipped because my fingers are hitting the next word before the spacebar has been fully released. I guess I'm sticking with the HHKB style fn key for now :P
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: U47 on Tue, 03 May 2016, 14:25:37
Question: has anyone tried to replicate SpaceFN in software on Linux? I love that I have my own SpaceFN hybrid on all my boards with TMK controllers, but using the built-in keyboard on my Linux laptop is posing a challenge.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: mike52787 on Tue, 03 May 2016, 14:43:50
Im a huge fan of this idea. I would definitely buy a board like this.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Wed, 04 May 2016, 00:45:33
Never tried but these tools were found and seems to be promising for start point.
Solution which works also on console in addition to Xorg would be preferable.

at-home-modifier:
https://gitlab.com/at-home-modifier/at-home-modifier-evdev/wikis/home

xcape:
https://github.com/alols/xcape
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: U47 on Wed, 04 May 2016, 13:19:14
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).
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: U47 on Tue, 26 July 2016, 14:24:29
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. :/
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: vincentalpha on Mon, 17 October 2016, 10:25:44
hi guys,
I love this feature and would like to apply spacefn with my XD60 using TMK controller. I am asking if you can guy help me to set up this feature with my keyboard. Sorry if this question has been answer before. I don't have the programming background to understand the concept and how to use. Please answer in plain English.
Thanks.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: hasu on Mon, 17 October 2016, 11:20:26
Keymap file for GH60 looks like this.
https://github.com/tmk/tmk_keyboard/blob/1610250cc360b7117c04506787aaaf57be5d4901/keyboard/gh60/keymap_spacefn.c
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Mon, 17 October 2016, 12:16:12
Thank you for the file, I am waiting for a couple of programmers to "upgrade" my GON to TMK and be able to implement the Space-Fn concept on it.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: vincentalpha on Sun, 23 October 2016, 09:44:20
I spend sometime to create this QMK code to make my XD60 programable.
Can you please let me have your comment?
Thanks.

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

Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: vincentalpha on Tue, 01 November 2016, 06:38:51
hey guys,
I am stuck with TMK software and the spacefn. Can you guys please help? Here's my layout and my screen short:
http://imgur.com/a/rZexl
Thanks.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: jcoffin1981 on Wed, 02 November 2016, 14:11:04
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Wed, 02 November 2016, 17:47:09
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.


Using the right thumb to activate the Fn plus ijkl for arrows is easier than use the Pinky, at least from my experience. The thumb is heavy and strong, so there is no problem to use it for Fn.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: JaydrVernanda on Thu, 12 January 2017, 15:17:47
KeyRemap4MacBook/Karabiner doesn't work with macOS Sierra. Is there another way to set up SpaceFN on a MacBook with software alone?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: HeroXLazer on Tue, 14 February 2017, 18:47:33
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Tactile on Tue, 14 February 2017, 18:59:08
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?

There are no hardware limitations. You can program it onto a Teensy 2.0.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: HeroXLazer on Wed, 15 February 2017, 22:02:49
Okay, what about an ATMEGA32U2?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: pixelpusher on Wed, 15 February 2017, 22:23:21
Just just freaking fn on capslock.  who needs capslock?  OH, and if you do, fn shift
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: U47 on Thu, 16 February 2017, 18:09:40
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 how I've implemented it using Hasu's HHKB controller, which uses TMK on an ATMega32U4. Pretty easy to convert it to any layout on any board or controller that uses TMK.

https://github.com/U47/tmk_keyboard/blob/a2e26010d341e7c54073ee7239389cc2d77ccf5d/keyboard/hhkb/keymap_u47.c
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: U47 on Sun, 20 August 2017, 19:28:39
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: asgeirtj on Wed, 27 September 2017, 16:39:48
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?  :)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Wed, 27 September 2017, 17:48:41
Just just freaking fn on capslock.  who needs capslock?  OH, and if you do, fn shift

That position is ideal for Control, that is why SpaceFN comes really handy. The best of both worlds.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: U47 on Thu, 28 September 2017, 23:10:04
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?  :)

If you have Karabiner Elements, it's been merged upstream. You can find it by opening Preferences > Complex Modifications > Add Rule > Import more rules from the internet, and importing SpaceFN (it's under Emulation Modes).

Haven't had a chance to see about implementing something along the lines of TMK's oneshot modifiers, so I'm finding dropped spaces in out-of-order releasing of space. Minor annoyance, but annoying nonetheless.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Nerarith on Tue, 10 October 2017, 14:41:39
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: marsbars on Wed, 11 October 2017, 07:38:38
SpaceFN is such a fantastic idea! Thanks a lot for that.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Pro XKB on Wed, 11 October 2017, 13:46:58
Quote
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: U47 on Thu, 12 October 2017, 00:15:50
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.

Not that I'm aware of. I looked into it a year or so ago but decided not to pursue it. I didn't want to devote time to making it work in X since I was using Wayland, didn't want to spend the effort hacking away at the USB HID driver level, and couldn't find out where it might fit within Wayland. Since all my desktop keyboards run TMK/QMK and I just implement it there, I just don't use my laptop keyboard all that much.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: helpme on Fri, 10 November 2017, 14:29:04
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Ngt on Tue, 14 November 2017, 14:43:55
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.


I'm using SpaceFn on TMK as well. I'd be really interested in how to play with the activation time as well.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ljosa on Thu, 28 December 2017, 18:48:22
I wanted to use SpaceFn with Linux, so I implemented it in the Xorg input driver. The code is on GitHub:
https://github.com/ljosa/xf86-input-evdev-spacefn

This web page describes the implementation and how to build, install, and configure it:
http://www.ljosa.com/~ljosa/software/spacefn-xorg/

This algorithm seems to work very well for me, but people type in different ways, so if you try it and find that it causes mistakes when you type, I'd love to hear from you. We may have to adjust the timeouts or revise the algorithm. A big thanks to spiceBar for coming up with the idea and describing it so eloquently.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: mike-y on Tue, 02 January 2018, 14:09:53
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Giorgio on Tue, 02 January 2018, 14:51:11
99% is a little bit too low considering that it's my most used key
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Tue, 02 January 2018, 15:15:51
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


These are very interesting tips for people that may want to implement the Space-FN at the hardware level. Thank you for sharing them.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: mike-y on Tue, 02 January 2018, 15:20:06
99% is a little bit too low considering that it's my most used key

during normal typing sessions, I'd say it's 100% accurate.  it's only when I'm paused and not really typing freely that I might get a long press instead of a space.  but in over two weeks of using this setup, I can say that this has only happened maybe 2 or 3 times (and that was during the first couple of days as I was getting used to it) 

That still may be too much for some people, but I've made far, far more typos than that anyway, so for me, it's a non-issue.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ljosa on Tue, 02 January 2018, 15:38:47
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: Giorgio on Tue, 02 January 2018, 15:51:00
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ljosa on Tue, 02 January 2018, 16:15:40
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

When it's ambiguous whether you mean to type a space or modify another key, the implementation stores the keypress in a buffer until it becomes clear what you meant to do. For instance, when I press down space and then press down L real quick, nothing happens right away. But if 200 ms goes by, or if I release L, then I end up typing a right arrow. And if I release space before I release L, then I end up typing a space followed by L. The "How it works" section of http://www.ljosa.com/~ljosa/software/spacefn-xorg/ describes it in some detail. There are a number of rules for deciding what to do. Happy to answer questions.

Perhaps TMK and QMK do something similar under the covers?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: mike-y on Tue, 02 January 2018, 17:39:10

Perhaps TMK and QMK do something similar under the covers?

I'll can test this more when I get home, as I'm using a different board at work this week (I like to rotate them so they don't get jealous :D ). 

from what I can remember, it doesn't actually send the space on the initial key press, but rather on the key release - as long as you release space before 200ms.  If you press your L key during the time the space is down (regardless of time), you get your right arrow. if you release space after 200ms, and have not touched another key, you've gone past the "hot zone" and no space instruction is sent at all.

Ok, got home and ran some tests on my redscarf II with the spacebar set to dual-role Function key, acting as both space and Fn. 

In any situation where the spacebar is tapped/held for less than 200ms, you always get a space, no matter what.  I have the 5 key bound to F5 on layer 1.  Layer 1 does not become active until space is held for longer than 200ms.  you can spam space and the 5 key as fast as you want, and you'll always get a space and a "5", even if you are holding down space when you press "5", as long as you release the space before 200ms is up. 

once you pass 200ms, you'll get F5.  layer 1 is never activated until you hold space for longer than 200ms.  So if you are a really fast typist, you'll never accidentally activate Layer 1 when typing fast.   you have to deliberately hold down space to activate your layer.

If you hold down space for longer than 200ms, the keyboard will not send a space, and only the key activated by the layer.  If you hold down space (longer than 200ms) and then release (without pressing any other key), no space will be sent from the keyboard.

if you need a repeating space, you double-tap space and hold down on the second tap, and you have your repeating space until you release.

so far, this has been working perfect for me, and I never accidentally activate the layer during normal typing sessions.


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: WallofYawn on Thu, 08 March 2018, 15:51:31
Hoping someone here can help me out.

Sierra 10.12.6, Early 2015 Macbook Pro, Karabiner-Elements 11.6.0, Acgam AG6X 60% keyboard plugged in.


Every function of SpaceFn works... Except for space+"m" being backtick and space+"," being tilde... Even weirder, it completely removes the ability to type those characters the normal way (in this case Fn+Esc= "`" Fn+shift+Esc = "~")...


I haven't peeked at the json yet, but has anybody come across this issue?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ljosa on Thu, 08 March 2018, 17:21:47
WallofYawn, SpaceFn recently became usable with Karabiner-Elements with the "simultaneous_options" feature. (Until now, rollover has not worked correctly.) You need to install the most recent beta, version 11.6.6. The released version 11.6.0 is too old.

For config, you can use this config of wincent's as a starting point and adapt it: https://github.com/wincent/wincent/commit/8fe03134e1c5201264ed2f1e5373c8720e2019f8

That's what I did, and I just verified that I can bind space+something to grave_accent_and_tilde and it works.

You'll want to follow Issue #877: https://github.com/tekezo/Karabiner-Elements/issues/877
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: WallofYawn on Thu, 08 March 2018, 22:05:46
ljosa,

Thanks a bunch. I've upgraded to 11.6.6, but I'm still a bit lost... Here's what I have, maybe you could point me in the right direction?

Code: [Select]
{
                                "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"
                            }


I've got space+ijkl mapped to up,left,down,right. Space+b equals space... But I still can't get space+m or space+comma to register grave or tilde...

Furthermore, with the "old" way, I can get space+m to output a grave accent. Here's the code for that:

Code: [Select]
,
                            {
                                "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
                                  }
                                ]
                              }


Final edit, I promise...


Okay, So... shift+space+m or comma = ~. That's less than ideal, as I'd rather they be two separate keys, only so my fingers don't have to contort as much. I guess it's a fix for now, unless there's a way to isolate that tilde or combine shift+space only for this particular mapping. Thanks for your help!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ljosa on Fri, 09 March 2018, 10:33:05
WallofYawn,

The attached karabiner.json gives you Space+b for space, Space+h/j/k/l for left/down/up/right, Space+m for PgDn, Space+comma for PgUp, Space+period for backtick and Space+slash for tilde.

You can modify it from there to what you want. Note that there are TWO modifiers for each key combination: one for when the keys are pressed simultaneously and one for when the SpaceFN variable is already set.

I haven't figured out yet how to prevent space from autorepeating.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ander on Sat, 10 March 2018, 02:40:46
I'd posted here asking how to try this with the Dvorak layout. But I've now followed lejboua's suggestion (https://geekhack.org/index.php?topic=51069.msg1616853#msg1616853) and installed TouchCursor (http://martin-stone.github.io/touchcursor/help.html), which makes it easy: You just change the default keys to their Dvorak equivalents, or in whatever layout you're using.

I've limited my changes to just the navigation keys, as I'd rather control things like Delete and Insert in a more fail-safe way. but I must say, SpaceFN is a very interesting idea, and it does seem quite comfortable and natural to movee cursor this way.

The only quirk I've run into is that, being an exceptionally fast typist [blush], I occasionally type a space, then press a toggle key before I've completely released the spacebar—and suddenly find the cursor isn't where I expected it to be. So if it's not your habit to release the spacebar quickly, you have to practice that.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: islisis on Mon, 12 March 2018, 12:30:03
ljosa:

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)
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ljosa on Wed, 14 March 2018, 02:02:50
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)

Islisis, I wasn't aware of AtHomeModifier when I made xf86-input-evdev-spacefn. I tried to look at the code of AtHomeModifier just now, and the logic appears to be similar. I haven't tried AtHomeModifier or studied its code enough to be able to say anything useful about subtle differences.


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: islisis on Wed, 14 March 2018, 11:05:48
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ljosa on Fri, 16 March 2018, 19:06:30
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: islisis on Mon, 19 March 2018, 06:14:38
that's the author of Interception! (http://www.oblita.com/interception)
if that api is ported to linux a great number of avenues might open up (keyboard+mouse combos)...
i'm guessing the downside is that all non-remapped input becomes rerouted, hopefully a small enough price to pay for wide-compatibility
two other scriptable implementations seem to exist!
https://github.com/myfreeweb/evscript
https://github.com/wbolster/evcape
thanks for all your responses!
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Wed, 11 April 2018, 18:50:06
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.


Caps2esc looks interesting, it would be worth digging further.

I have tried for some time to create an implementation of SpaceFN for Linux, starting from xcape.

I worked on this for several weeks, but had to give up in the end. It's simply not doable with the XRecord extension, which is too weak. If you want to prove me wrong, go ahead, good luck. I can even provide my source code to anyone ready to take on this.

Now Caps2esc seems to use a different method of interception, and it may be possible with this method.

I hope someone will try.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: etatauri on Thu, 12 April 2018, 03:26:34
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: bizzy11 on Fri, 13 April 2018, 11:36:37
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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Fri, 13 April 2018, 16:55:52
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: emenelopee on Fri, 13 April 2018, 17:16:21
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.

It actually works quite well. I have a split space custom (image in my footer): right space is [space] when tapped and [Fn] when held; left space is [backspace] as regular and [del] with [Fn]. Ditto with arrows on [ESDF] on the [Fn] layer. Everything is on the homerow, especially with [Caps] set as [Ctrl]. All through QMK btw.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: bizzy11 on Fri, 13 April 2018, 17:50:34
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sat, 14 April 2018, 18:38:47
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sat, 14 April 2018, 19:18:55
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sat, 14 April 2018, 21:55:32
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.


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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: bizzy11 on Sun, 15 April 2018, 12:34:26
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'm having a hard time adapting to the spacebar, so this might work better for me.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Sun, 15 April 2018, 12:59:53
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: stevep on Fri, 20 April 2018, 05:42:06
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 use, and can highly recommend, the Left Alt key.

The Alt keys are well-placed for GuiFN-like modifiers, albeit more so on some keyboards than others. You basically want a key on the bottom row that's easy to press with the thumb. The Alt keys make decent thumb keys and I consider it to be a terrible waste not to use them for something more useful.

GuiFN operations work best IMO with a left-hand key, and that's why I propose Left Alt rather than Right Alt/AltGr. Also it avoids any problem for those who use AltGr for accented/special characters etc.

You may ask: How do I access Left Alt? Well, I simply have moved the function of Left Alt to the Left-Win (Super) key.

This setup has the best of both worlds: The convenience of a thumb key but with no need to remap space to be dual-function.

Left thumb -> GuiFN
Right thumb -> Space

Both thumbs have useful jobs.


Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: abrasive on Wed, 29 August 2018, 07:26:11
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
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: bullett on Wed, 29 August 2018, 11:55:31
I have been using SpaceFn with my Obins Anne Pro and I'm loving it.
When I use the keyboard connect through usb everything works fine but when it connects via bluetooth it doesn't.

From time to time the Ctrl, Shift, Alt or Windows key will stick (stay pressed down) and even if I press it again nothing happens. The only way to release the key is to stop the spacefn script than press and release the key.

I'm guessing there some latency problem with the bluetooth connection, I tried changing the delay and timeout values but the problem continues (btw, this only happens with the spacefn script running, it's not a problem with the keyboard)

Any suggestions of what I can change on the script to prevent the keys from "sticking"
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Sun, 16 September 2018, 22:46:41
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

Yeah! Very cool to see that someone has eventually done this for Linux.

I tried some time ago, using the XRecord extension, but failed after several weeks. I believe it cannot be done with the XRecord extension (it's not powerful enough and it has serious bugs).

I have downloaded your sources and tried to compile the program.

I'm using Ubuntu 16.04.

I have installed libevdev-dev manually. libevdev2 was already installed on the system. I do have /dev/uinput.

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?
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: abrasive on Sun, 16 September 2018, 23:43:34
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.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: ideus on Mon, 17 September 2018, 19:06:20
I have been using the FN layout for a year now. I just began using the traditional HHKB diamond layout for the arrows and FN at the right and I became very surprised that it is very easy to use as well. I have now hard coded it on my boards and I am using the FN layout as well with Touch Cursor. Best of both worlds I think.
Title: Re: The SpaceFN layout: trying to end keyboard inflation
Post by: spiceBar on Mon, 17 September 2018, 19:47:45
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.

OK, I have just opened the issue on Github.