Author Topic: The SpaceFN layout: trying to end keyboard inflation  (Read 250111 times)

0 Members and 1 Guest are viewing this topic.

Offline mike-y

  • Posts: 75
  • Location: California, USA
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #350 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
« Last Edit: Tue, 02 January 2018, 15:25:45 by mike-y »

Offline Giorgio

  • Posts: 1846
  • Location: Italy
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #351 on: Tue, 02 January 2018, 14:51:11 »
99% is a little bit too low considering that it's my most used key

Offline ideus

  • * Exalted Elder
  • Posts: 8123
  • Location: In the middle of nowhere.
  • Björkö.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #352 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.

Offline mike-y

  • Posts: 75
  • Location: California, USA
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #353 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.

Offline ljosa

  • Posts: 15
  • Location: Massachusetts
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #354 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.

Offline Giorgio

  • Posts: 1846
  • Location: Italy
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #355 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

Offline ljosa

  • Posts: 15
  • Location: Massachusetts
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #356 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?

Offline mike-y

  • Posts: 75
  • Location: California, USA
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #357 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.


« Last Edit: Tue, 02 January 2018, 22:51:04 by mike-y »

Offline WallofYawn

  • Posts: 12
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #358 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?

Offline ljosa

  • Posts: 15
  • Location: Massachusetts
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #359 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

Offline WallofYawn

  • Posts: 12
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #360 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!
« Last Edit: Thu, 08 March 2018, 23:00:04 by WallofYawn »

Offline ljosa

  • Posts: 15
  • Location: Massachusetts
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #361 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.

Offline ander

  • * Esteemed Elder
  • Posts: 1186
  • Location: Vancouver, BC
  • I type, therefore I am
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #362 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 and installed TouchCursor, 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.
« Last Edit: Sat, 10 March 2018, 03:09:54 by ander »
We are not chasing wildly after beauty with fear at our backs. – Natalie Goldberg

Offline islisis

  • Posts: 120
  • Location: Tokyo, Japan
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #363 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)

Offline ljosa

  • Posts: 15
  • Location: Massachusetts
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #364 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.



Offline islisis

  • Posts: 120
  • Location: Tokyo, Japan
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #365 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?
« Last Edit: Wed, 14 March 2018, 11:07:59 by islisis »

Offline ljosa

  • Posts: 15
  • Location: Massachusetts
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #366 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.

Offline islisis

  • Posts: 120
  • Location: Tokyo, Japan
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #367 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!
« Last Edit: Mon, 19 March 2018, 06:30:40 by islisis »

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #368 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.

Offline etatauri

  • Posts: 19
  • Location: California, USA
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #369 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.
Input Club K-Type / Vortex Pok3r / Magicforce 21 / Razor Blackwidow
MX Clear / MX Blue / IC Halo Clear / NK Box Pale Blue / NK Box Navy
SP DSA HC Dolch / SP Dye Sub DSA / SP SA Dasher / MD MT3 /dev/tty / KC Strong Spirit

Offline bizzy11

  • Posts: 88
  • Location: Los Angeles
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #370 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?
FC660C | FC980C

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #371 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.

Offline emenelopee

  • Posts: 398
  • *klomp klomp klomp* I step on your house 🦖
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #372 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.

Offline bizzy11

  • Posts: 88
  • Location: Los Angeles
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #373 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.
FC660C | FC980C

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #374 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.

Offline ideus

  • * Exalted Elder
  • Posts: 8123
  • Location: In the middle of nowhere.
  • Björkö.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #375 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.

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #376 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.

Offline bizzy11

  • Posts: 88
  • Location: Los Angeles
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #377 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.
FC660C | FC980C

Offline ideus

  • * Exalted Elder
  • Posts: 8123
  • Location: In the middle of nowhere.
  • Björkö.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #378 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.

Offline stevep

  • Posts: 36
    • Colemak Mod-DH
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #379 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.


« Last Edit: Fri, 20 April 2018, 05:48:25 by stevep »

Offline abrasive

  • Posts: 2
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #380 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

Offline bullett

  • Posts: 1
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #381 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"

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #382 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?

Offline abrasive

  • Posts: 2
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #383 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.

Offline ideus

  • * Exalted Elder
  • Posts: 8123
  • Location: In the middle of nowhere.
  • Björkö.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #384 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.

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #385 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.

Offline derekL92

  • Posts: 1
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #386 on: Sun, 10 March 2019, 21:43:16 »
Is this spacefn layout implementable in "New Poker 2" by using the stock programming like "space+w=up arrow", "space+a=left arrow", etc. ?

Offline wellbeing44

  • Posts: 71
  • Location: Singapore
  • kebord good kebord fun yum yum
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #387 on: Mon, 11 March 2019, 03:20:35 »
With QMK, I believe there is a way to make the spacebar do SpaceFN, and additionally also do repeating space upon double tap. This would remove the need for the unintuitive B key.

Offline sflash

  • Posts: 2
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #388 on: Mon, 29 June 2020, 17:08:16 »
Can someone help me rebind or create additional config with changed rules for SpaceFN+U,O,H,N. I mean like in Vortex Core
SpaceFN+H - Home
SpaceFN+N - End
SpaceFN+U - PageUp
SpaceFN+O - PgDn

Thanks!

Offline ideus

  • * Exalted Elder
  • Posts: 8123
  • Location: In the middle of nowhere.
  • Björkö.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #389 on: Mon, 29 June 2020, 17:13:41 »
Just use touchcursor. You will save yourself a lot of headaches.

Offline sflash

  • Posts: 2
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #390 on: Mon, 29 June 2020, 18:00:21 »
Sorry, just found solution after reading Karabiner Docs. Solution is export config with:
Open config folder from Preferences > Misc. Copy the karabiner.json file. Then replace this code:

Code: [Select]
                    {
                        "description": "SpaceFN: Space+u to Home, Space+o to End",
                        "manipulators": [
                            {
                                "conditions": [
                                    {
                                        "name": "spacefn_mode",
                                        "type": "variable_if",
                                        "value": 1
                                    }
                                ],
                                "from": {
                                    "key_code": "u",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "home"
                                    }
                                ],
                                "type": "basic"
                            },
                            {
                                "conditions": [
                                    {
                                        "name": "spacefn_mode",
                                        "type": "variable_if",
                                        "value": 1
                                    }
                                ],
                                "from": {
                                    "key_code": "o",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "end"
                                    }
                                ],
                                "type": "basic"
                            }
                        ]
                    },
                    {
                        "description": "SpaceFN: Space+h to Page Up, Space+n to Page Down",
                        "manipulators": [
                            {
                                "conditions": [
                                    {
                                        "name": "spacefn_mode",
                                        "type": "variable_if",
                                        "value": 1
                                    }
                                ],
                                "from": {
                                    "key_code": "h",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "page_up"
                                    }
                                ],
                                "type": "basic"
                            },
                            {
                                "conditions": [
                                    {
                                        "name": "spacefn_mode",
                                        "type": "variable_if",
                                        "value": 1
                                    }
                                ],
                                "from": {
                                    "key_code": "n",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "page_down"
                                    }
                                ],
                                "type": "basic"
                            }
                        ]
                    },

to this:

Code: [Select]
                    {
                        "description": "SpaceFN: Space+u to Page Up, Space+o to Page Down",
                        "manipulators": [
                            {
                                "conditions": [
                                    {
                                        "name": "spacefn_mode",
                                        "type": "variable_if",
                                        "value": 1
                                    }
                                ],
                                "from": {
                                    "key_code": "u",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "page_up"
                                    }
                                ],
                                "type": "basic"
                            },
                            {
                                "conditions": [
                                    {
                                        "name": "spacefn_mode",
                                        "type": "variable_if",
                                        "value": 1
                                    }
                                ],
                                "from": {
                                    "key_code": "o",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "page_down"
                                    }
                                ],
                                "type": "basic"
                            }
                        ]
                    },
                    {
                        "description": "SpaceFN: Space+h to PC Home, Space+n to PC End",
                        "manipulators": [
                            {
                                "conditions": [
                                    {
                                        "name": "spacefn_mode",
                                        "type": "variable_if",
                                        "value": 1
                                    }
                                ],
                                "from": {
                                    "key_code": "h",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "left_arrow",
                                        "modifiers": "left_command"
                                    }
                                ],
                                "type": "basic"
                            },
                            {
                                "conditions": [
                                    {
                                        "name": "spacefn_mode",
                                        "type": "variable_if",
                                        "value": 1
                                    }
                                ],
                                "from": {
                                    "key_code": "n",
                                    "modifiers": {
                                        "optional": [
                                            "any"
                                        ]
                                    }
                                },
                                "to": [
                                    {
                                        "key_code": "right_arrow",
                                        "modifiers": "left_command"
                                    }
                                ],
                                "type": "basic"
                            }
                        ]
                    },

Offline jamster

  • Posts: 1091
  • Location: Asia
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #391 on: Wed, 08 July 2020, 01:37:33 »
I'm trying a modified version of this SpaceFN idea. I'm typically a proponent of more rather than less keys, and a physically separated nav cluster, but this idea lends itself especially well to crammed keyboards such as those found on a laptop.

It's definitely taking a bit of effort to adjust to, especially when using the layered arrow keys with a modifier like Control (for forward/back web browsing) where I really have to stop completely and think about the key press sequence, but I can see the value in this idea.

Initially I had started off with arrow keys on the left hand, but found that it interfered too much with Control-C/V/X as mentioned earlier in this thread. Moved to the right hand and things became less confused.

There's an unexpected downside with running this at the software level- Touchcursor takes a little while to autostart on computer bootup (even on a totally modern PC). It's long enough to have bitten me a couple of times and I just have to wait for a while before the remaps take effect.

Overall, from the perspective of a TKL user, I am really liking this idea.

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #392 on: Wed, 08 July 2020, 04:36:21 »
I'm trying a modified version of this SpaceFN idea. I'm typically a proponent of more rather than less keys, and a physically separated nav cluster, but this idea lends itself especially well to crammed keyboards such as those found on a laptop.

It's definitely taking a bit of effort to adjust to, especially when using the layered arrow keys with a modifier like Control (for forward/back web browsing) where I really have to stop completely and think about the key press sequence, but I can see the value in this idea.

Initially I had started off with arrow keys on the left hand, but found that it interfered too much with Control-C/V/X as mentioned earlier in this thread. Moved to the right hand and things became less confused.

There's an unexpected downside with running this at the software level- Touchcursor takes a little while to autostart on computer bootup (even on a totally modern PC). It's long enough to have bitten me a couple of times and I just have to wait for a while before the remaps take effect.

Overall, from the perspective of a TKL user, I am really liking this idea.

I definitely prefer keyboards with a dedicated nav cluster. I did not create SpaceFN to promote keyboards that have no arrow keys.

The idea for SpaceFN was: what do you do when you do not have the nav cluster?

At the time I created SpaceFN, I was experimenting with smaller keyboards like the Poker X and the HHKB. I had already purchased several TKLs, liked them a lot, and wanted to see if smaller would be better.

I did not like the default implementation for the navigation keys on the Poker X and HHKB. So I had to figure out something else. I have invested weeks of works on this problem, maybe months actually.

From this personal struggle with small keyboards, both SpaceFN and GuiFN came to be.

Now, almost seven years after this work, where do I stand?

To be honest, I seldom use SpaceFN or GuiFN nowadays. I use SpaceFN when I need to use my HHKB, my Poker X, my GH60 or my Poker 2. For all of them, I have hardware converters (all made by Hasu), so I don't do the conversion at the OS level.

But my keyboard layout of choice is now the FC660C layout or similar.

It's basically a 60% keyboard layout with arrows. It's one or one and a half column larger than a strictly 60% keyboard. It does not look as neat and minimalist as a 60% keyboard, but the compromise is worth it.


246725-0


Most people reaction to it will be that there is wasted space on the right side, but they are wrong. Remember, your hands don't see. The space at the right of the keyboard is very useful to find your way to the Backspace, Del, Enter and arrow keys without looking. It's not a bug, it's a feature, and it's one of the best features of this keyboard, one that you can only appreciate after having used it for a while.

I remap the left Ctrl key to be a second Fn key, and remap CapsLock to be the left Ctrl key.

I should probably make a separate post to explain in details how I remap the FC660C layout.

Anyway, here is my general advice after all these years experimenting with small keyboards:

- If you can, do not ever purchase a keyboard that has no dedicated arrow keys, no matter how good it looks, because your productivity will suffer.

- If your keyboard has no dedicated arrow keys, maybe you could give SpaceFN a try. If you like it, now your choice of keyboards is virtually unlimited, because SpaceFN works on any keyboard layout.

Offline jamster

  • Posts: 1091
  • Location: Asia
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #393 on: Wed, 08 July 2020, 05:29:26 »
Interesting to get your very long term view on this concept.

I was motivated to try these function layer maps because of the responses to a thread I started, asking about the usability of 60% and smaller keyboards. Some people seem entirely happy with smaller keyboards which lack separated, dedicated nav keys, and these same people are using them on a daily basis as actual work keyboards, rather than as Instagram pretties which I still assume drives a lot of the mech board market these days.

I have been using a BTC5100 with these remaps. Because the BTC has dedicated arrows and some nav keys, but these are not physically spaced out- the board is one big matrix of keys mashed together. This lack of spacing has made the board incredibly frustrating to use. The remaps, even though they are taking an effort to get used to, do make the keyboard bearable. I guess some people are just better at muscle memory and less reliant on tactile spacing.

The board you posted would still be usable to me. Arrows are not separated, but having the right arrow set out of the main cluster would still allow for location via touch. Hm, it's also electro-capacitive... very nice.
« Last Edit: Wed, 08 July 2020, 05:33:24 by jamster »

Offline JCraftCables

  • Posts: 99
    • Instagram
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #394 on: Wed, 08 July 2020, 06:28:23 »
Cool... I actually, never thought of spacebar as an FN key!

Offline goosemondude

  • Posts: 1
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #395 on: Mon, 01 March 2021, 09:40:26 »
Preface:
At the risk of sounding pretty ignorant, I have looked and haven't found much on the below question. I did the basic can-i-google runthrough and skimmed here and can't quite figure it out.

Question:
Is it possible for this spacefn autohotkey script for windows to work with git for windows command line?

Is there something I need to do to to get it to work or is there just not a way for the keypress inputs to translate through git for windows command line?

Update:
I ran the windows autohotkey script as administrator and now I see ~~~~~~~ get spit out when I hold down the space button in git bash...

Update 2:
Switched to cygwin and am just going to go with that. Working well.

Last Update:
I wish I had realized that TouchCursor existed because I've found it to work better than the Windows AutoHotKey script!
I'm able to use git for windows with it too which is what I originally wanted.

Thanks!
« Last Edit: Tue, 02 March 2021, 20:53:38 by goosemondude »

Offline U47

  • Posts: 99
  • Location: YEG
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #396 on: Sun, 14 March 2021, 22:38:18 »

Anyway, here is my general advice after all these years experimenting with small keyboards:

- If you can, do not ever purchase a keyboard that has no dedicated arrow keys, no matter how good it looks, because your productivity will suffer.

My own counterpoint:
Try many things, especially boards without dedicated arrow keys.
In my case, and I'm sure many others, my productivity has vastly improved from a lack of dedicated arrow keys—and further, by using an ortholinear layout, and further still, from 40% size.

The less my fingers have to travel (40%), and to travel to a more consistent destination (ortho) results in far fewer typos. Using SpaceFN and other layers, and even chorded combinations, vastly dwarfs any convenience provided by arrow keys. I can access all nav keys from either home row or adjacent to it. Zero time wasted moving to an arrow cluster and then finding my homing key when moving my right hand back.

Take that a step further and invest in learning the advanced bindings of your text editor (for me vim, but others are fine too) and you will see even further performance gains.

If you type for a living, and you are prepared to work to improve your typing and workflow, you absolutely should experiment. Keyboards, layouts, plover—everything. But it requires work, so you have to be prepared to buckle down and put up with a performance loss until your ability ramps up.

Offline ideus

  • * Exalted Elder
  • Posts: 8123
  • Location: In the middle of nowhere.
  • Björkö.
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #397 on: Mon, 15 March 2021, 00:14:02 »

Anyway, here is my general advice after all these years experimenting with small keyboards:

- If you can, do not ever purchase a keyboard that has no dedicated arrow keys, no matter how good it looks, because your productivity will suffer.

My own counterpoint:
Try many things, especially boards without dedicated arrow keys.
In my case, and I'm sure many others, my productivity has vastly improved from a lack of dedicated arrow keys—and further, by using an ortholinear layout, and further still, from 40% size.

The less my fingers have to travel (40%), and to travel to a more consistent destination (ortho) results in far fewer typos. Using SpaceFN and other layers, and even chorded combinations, vastly dwarfs any convenience provided by arrow keys. I can access all nav keys from either home row or adjacent to it. Zero time wasted moving to an arrow cluster and then finding my homing key when moving my right hand back.

Take that a step further and invest in learning the advanced bindings of your text editor (for me vim, but others are fine too) and you will see even further performance gains.

If you type for a living, and you are prepared to work to improve your typing and workflow, you absolutely should experiment. Keyboards, layouts, plover—everything. But it requires work, so you have to be prepared to buckle down and put up with a performance loss until your ability ramps up.


I have found my personal sweet spot at sixty-keyboards with no arrows. I use a diamond-shaped arrow cluster at the right and using a modifier to activate it. It works wonders and my productivity is good. However, I can understand those that do not have the time and interest in exploring anything under full size. For those, the arrow, the nav and the num clusters should be a necessity.

Offline asgeirtj

  • Posts: 535
  • Location: Iceland
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #398 on: Thu, 27 April 2023, 04:40:21 »
Has anyone gotten TouchCursor's function to disable using certain programs? It just doesn't work at all for me whether I use the crosshair thing or just manually enter the process name. No matter what program it is that I'm trying to configure the disable for. To disable it in Edge it doesn't work to mut in msedge.exe or to use the crosshair to point at Edge (which gives some asian lookin letters result that I don't understand actually).
Leopold FC900 w/ 67g Purple Zealios - Silver Duck Octagon w/ 62 Purple Zealios