Jump to content




Optimized Key Layout


4 replies to this topic

#1 H4X0RZ

  • Members
  • 1,315 posts
  • LocationGermany

Posted 07 November 2015 - 09:00 PM

tl;dr These scripts will generate a keyboard layout by sorting a giving piece of code and arranging the keys by how often the given char appears in the code.

I were bored today so I started this little "project". It isn't anything special, it just allows you to generate a keyboard layout (for CC) which will/should fit your needs. It consists out of two programs. One that analyzes a given file (which should contain code) and the other one takes the output from the first and converts that into an executable layout. When generating it will sort the characters of the given file by how often they appear and then gives them places according to their "worth". (the most used keys get a more centralized place on the keyboard. G is the key worth the most, then it goes to the left and right from G (alternating) and then the other two "layers" of keys. Then the same happens with capitalized (shift) keys). This method *should* give you the most optimized layout (according to the code provided)

Using it is easy:
download 2BiacX78 and EFVX27ye (I have saved them as "analyze" and "generate" but you can decide for yourself)
then choose some big file containing code (maybe one you wrote. I were using the minified code from Howl) and enter
analyze <file name>
This will save a dump of the appearing chars (and their probability) into "output". After that enter
generate output
This will generate the finished executable which will set your computer up for the new layout. I'm using a simplified version of my event remapper for that (it is included at the top of the layout).

The "Howl layout" looks like this for example:
Spoiler
With this layout "f" would act as spacebar (but the normal spacebar could still be used), "g" becomes "e", "h" becomes "n" etc. Sometimes if brackets are used strange (idk if that is even possible in Lua) it could happen that an opening/closing bracket is available from the normal keyboard but for it's counterpart you need shift so look out for that.

The way it is done right now has to leave some characters out because I only have a german keyboard so I could only write a full "priority list" for the normal german layout (QWERTZ). If anyone want's to write a "priority list" for the standard english layout please do so.

Greetings,
~H4X0RZ

Edited by H4X0RZ, 07 November 2015 - 09:13 PM.


#2 Creator

    Mad Dash Victor

  • Members
  • 2,168 posts
  • LocationYou will never find me, muhahahahahaha

Posted 07 November 2015 - 09:25 PM

So why exactly should the first file be code? Can't it be a text file?

#3 H4X0RZ

  • Members
  • 1,315 posts
  • LocationGermany

Posted 07 November 2015 - 10:00 PM

View PostCreator, on 07 November 2015 - 09:25 PM, said:

So why exactly should the first file be code? Can't it be a text file?
It can be anything but a code file "teaches" the layout more about the appearance of characters in a Lua file.

#4 SquidDev

    Frickin' laser beams | Resident Necromancer

  • Members
  • 1,427 posts
  • LocationDoes anyone put something serious here?

Posted 08 November 2015 - 11:22 AM

This is kinda cool, (though I'm not sure I see the point). Also, it uses Howl so I have to approve :P.

One thing though: You might want to delegate to the os.pullEvent method rather than os.pullEventRaw - otherwise you won't catch terminate events.

#5 H4X0RZ

  • Members
  • 1,315 posts
  • LocationGermany

Posted 08 November 2015 - 01:51 PM

View PostSquidDev, on 08 November 2015 - 11:22 AM, said:

This is kinda cool, (though I'm not sure I see the point). Also, it uses Howl so I have to approve :P.

One thing though: You might want to delegate to the os.pullEvent method rather than os.pullEventRaw - otherwise you won't catch terminate events.

TBH, there is no point in using this :P All it does is remap your keyboard so the most used characters (that's why you should do it with a *large* file of *code*) are more centralized.

There are some points which make it completely unusable:
  • Shifting doesn't do the same as for a "normal" keyboard. On a "normal" kb it reveals the capitalized counterparts of the keys. My generator will just sort by the appearance of the characters so capitalized/not-capitalized characters are mixed on both "layers" (shifted and "normal") and they aren't on the same keys. For example the "Howl layout": "a" is equal to "a" (lol) and "U" is equal to "A".
  • It's extremely hard to recognize the position of every key unless you have some magic keyboard.
Thanks for telling me to switch from pullEventRaw to pullEvent, haven't thought about that!

//Off-Topic
Maybe I'm going to write something that works like ASETNIOP because I'm really interested in how that works (writing text using chords)





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users