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

0 Members and 1 Guest are viewing this topic.

Offline utku

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


« Last Edit: Fri, 29 November 2013, 15:13:29 by utku »

Offline spiceBar

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

Offline utku

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

Offline spiceBar

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

Offline Matias

  • * Commercial Vendor
  • Posts: 517
  • Location: Toronto
    • http://matias.ca
SpaceFN vs. CapsLockFN+EnterFN
« Reply #54 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...  :-)


Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: SpaceFN vs. CapsLockFN+EnterFN
« Reply #55 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? ;-)

Offline Matias

  • * Commercial Vendor
  • Posts: 517
  • Location: Toronto
    • http://matias.ca
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #56 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.



Offline lydell

  • Posts: 42
  • Location: Sweden
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #57 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. 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, 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.)

Offline jorgenslee

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

Offline spiceBar

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

Offline Soarer

  • * Elevated Elder
  • Posts: 1918
  • Location: UK
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #60 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).

Offline utku

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

Offline spiceBar

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

Offline spiceBar

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

Offline ideus

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

Offline utku

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

Offline Matias

  • * Commercial Vendor
  • Posts: 517
  • Location: Toronto
    • http://matias.ca
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #66 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.  :)



Offline davkol

  •  Post Editing Timeout
  • Posts: 4994
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #67 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.

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #68 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.
« Last Edit: Sun, 01 December 2013, 13:48:32 by spiceBar »

Offline spremino

  • Posts: 362
  • Location: Italy
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #69 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.
A long space bar... what a waste of space!

Offline spiceBar

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

Offline spremino

  • Posts: 362
  • Location: Italy
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #71 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.
A long space bar... what a waste of space!

Offline spremino

  • Posts: 362
  • Location: Italy
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #72 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.
A long space bar... what a waste of space!

Offline spiceBar

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

Offline jeffgran

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

Offline spiceBar

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

Offline swill

  • * Elevated Elder
  • Posts: 3365
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #76 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:


Offline spiceBar

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

Offline swill

  • * Elevated Elder
  • Posts: 3365
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #78 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.  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...

Offline spiceBar

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

Offline swill

  • * Elevated Elder
  • Posts: 3365
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #80 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.  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...

Offline spiceBar

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

Offline swill

  • * Elevated Elder
  • Posts: 3365
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #82 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.  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.

Offline spiceBar

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

Offline swill

  • * Elevated Elder
  • Posts: 3365
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #84 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.

Offline spiceBar

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

Offline swill

  • * Elevated Elder
  • Posts: 3365
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #86 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.

Offline hasu

  • Posts: 3471
  • Location: Tokyo, Japan
  • @tmk
    • tmk keyboard firmware project
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #87 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.

Offline swill

  • * Elevated Elder
  • Posts: 3365
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #88 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).



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

Offline spiceBar

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

Offline swill

  • * Elevated Elder
  • Posts: 3365
  • Location: Canada eh
  • builder & enabler
    • swillkb.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #90 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.

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1672
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #91 on: Wed, 18 December 2013, 23:15:47 »
this is incredible. thanks!

Offline spiceBar

  • Thread Starter
  • Posts: 998
    • ChessTiger.com
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #92 on: Thu, 19 December 2013, 05:14:35 »
this is incredible. thanks!

What is incredible?

PS: I like your signature.

Offline yasuo

  • Posts: 978
  • Location: ID
  • spanengan puyeng newbie
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #93 on: Thu, 19 December 2013, 05:53:13 »
thanks your inspiring for make BSfn :))
Logitech MK220 Colemak DH
SplitSyml by Moz BlacksMx fuk blacks

2/3 8.5pm                                          in de la my september month ya da all get my fukka "fake message"

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1672
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #94 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...

Offline spiceBar

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

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1672
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #96 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.

Offline spiceBar

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

Offline domoaligato

  • * Exquisite Elder
  • Posts: 1672
  • Location: USA
  • All your base are belong to us!
    • All your base are belong to us!
Re: The SpaceFN layout: trying to end keyboard inflation
« Reply #98 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.

Offline spiceBar

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