Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Den

Pages: [1] 2 3 4 ... 18
Hacks / Re: Balanced Keyboard Layout
« on: March 22, 2017, 04:14:31 AM »
Updated KLA on my site with new Matrix keymap, which is Ergolinear with number row and two extra thumb keys. Therefore new BEAKL EZ Matrix layout. see attached. (Also fixed the unshifted letter to stay at the bottom left corner of the keycap.)

On actual keyboard, you can fill the numbers on the number row. I omitted them on KLA since I don't know how that would affect the scores. New BEAKL EZ Matrix scores similarly to BEAKL 5 Ergolinear, except 5 is somewhat better at code.

Also not shown is the ten-key layer that overlays the left hand. The math symbols are in the same place as normal or alt-gr layers, and the numbers are optimized as discussed earlier in this thread. Like so:
Code: [Select]
ten-key layer


Home fingers are 5102. Tab is hit with thumb on matrix layout. There is room for Enter at the pinky if you decide to include it.

It's ironic that having common bigrams close together reduces accuracy of word prediction.

Hacks / Re: Balanced Keyboard Layout
« on: March 19, 2017, 06:02:52 PM »
new goals:
  • more keys for gaming hotkeys
  • conjoin ten-keys math symbols into alt-gr layer
  • add number row and more thumb keys to ergolinear blueprint
  • retain some standard symbols unshifted (e.g. semicolon, slash)
  • may lose points in test, but should provide overall better intuitiveness and accessibility

  • Some games need a lot of hotkeys, especially for the left hand while driving the mouse with the right. Also they keys should be activated without any shifting in order give the best response time.
  • Output the same math symbols regardless if num-lock or alt-gr is down.
  • Returning number row will provide many benefits. Provides a simple way to type numbers. Provides more keys for gaming and for ten-key.
  • Certain keys have been hijacked by other input methods (ex. microsoft double pinyin dilemma as seen previously in this thread). So it behooves to retain those keys for accessibility and backward compatibility.
  • For the most part, we have optimized the letters very near to the theoretical limits (based on current understanding). So more care toward improving the overall keyboard experience.

  • Number row left hand could contain +=*. Accessible by both ten-key and alt-gr with the same fingers.
  • Standard unshifted symbols would include .,'-/;  ... With .,-/ the same as their ten-key places

Some fiddling around produced this...

Cheers, Ian

looks quite neat. although i kinda want R closer to E.

btw i have some ideas to improve Vowel Sandwich and TEA Ring, but haven't updated the screenshots.

@Den : Which would you say is your best layout for swiping?

I recommend Vowel Ring as closer to ideal, but Vowel Sandwich is also fun and intuitive.

Busy comparing layouts, I redid mine a bit to put numpad on left and letters where 4-0 where.

"Evaluating" them by counting swipe lengths for common bigrams/trigrams/quadgrams, scaled by frequency.

Initial results: (Lower is better)
Z3 (new layout) : 230.47
Z2 (letters same as Z1 posted above): 248.53
Qwerty: 467.58
Colmak: 530.83

ToDo: Dvorak, and suggestion from you.

What algorithm do you use? Just (x, y) distance between keys?

I suppose it's unfair to compare things like Colmak against this because design criteria were completely different. But if keyboard apps want to offer options then they should offer best layouts for swiping too...

If keyboard app makers and people who keep creating "custom" layouts which are just variants of qwerty and other ten-finger layouts don't even acknowledge that there could be better layouts, then by their silence and negligence have positioned themselves out of the argument. So they would have to bear with any results of technical tests. Not that they would care or even notice anyway. In that sense, no feelings could be hurt.

Hacks / Re: Balanced Keyboard Layout
« on: March 16, 2017, 09:18:54 PM »
thanks for comprehensive reply into the pinyin issue. i don't type chinese, so didn't know about double pinyin. it sounds reasonable since mandarin is very structured monosyllables. For maximum efficiency, you might even want to optimize double pinyin if possible (just like one optimizes English text). however that may be limited or impossible by the IME software.

Punctuations can be personalized to suit your purpose without much impact on the letters.

there may be need to have subsets of BEAKL for various usages. like BEAKL EZ was a first attempt to compromise between English and Mandarin (full) pinyin. for better compatibility, the semicolon may be taken into consideration. but better yet, have the layouts be independent of the IME or qwerty punctuation.

You could put CTRLs on the thumb cluster. or in the worst case, move them to outside the pinky on the home row.

@ is shifted.

2. my answers to your questions:
  • inward roller
  • bigrams either easy rolls or two hands. trigrams prefer 2-1 or 1-2.
  • vowels are some of the most common letters across all languages. that means the resulting best layouts wouldn't differ by much as far as vowels are concerned.
  • some/most of us layout enthusiasts obviously prefer a perfect layout for our personal use. but sometimes when you share computers and keyboards, such organizations would prefer a standard layout for all users. in such a case, it wouldn't be easy for users to customize the layout.

Tech Support / Re: Migration to HTTPS
« on: March 16, 2017, 11:17:13 AM »
I agree with Tim-Berners Lee that the conception of a separate URI from HTTP to HTTPS was a short-term solution that ripples into long-term mistake. It causes inconvenience for both users and webmasters.

The content for either URI are identical.  The content files on the server are one and the same, and three is no difference in what the user sees and experiences in browser.  So how does that warrant a different protocol and address? Other protocols like FTP and Telnet etc. do provide markedly different purpose, so they should require their own protocol.

The difference between http:// and https:// is not just one letter. The user has to type 8 additional, unnecessary characters at the beginning of every address in order to deserve security and privacy. The webmasters must include extraneous configurations to their servers to differentiate the two addresses (including opening additional ports), even though there is no practical difference to the content being served to users. So why must we burden both users and webmasters this way?

Tech Support / Re: Migration to HTTPS
« on: March 14, 2017, 05:42:31 PM »
Fortunately my webhost has some simple solutions to assist me to transition to SSL. My webhost gives me the option to use Let's Encrypt, which has been touted by many as a good way to get free certs. I can also easily "force SSL connections to your domain and subdomains".

However I'm still uncertain of the ramifications to this forum and the rest of the pages on this domain and subdomains. How badly would things get messed up, and how much effort to fix them? How many files do I have to manually update to make sure they work with the HTTPS URI?

Update (2017/03/14):
I simply acquired the certs from the webhost, which automatically enables https: to the entire domain. Forums and whole domain seem work in both HTTP and HTTPS without me doing anything. But some pages may still give insecure warnings due to mixed content. Not yet ready to force SSL connections on the domain. Probably test with subdomains first.

Tech Support / Migration to HTTPS
« on: March 14, 2017, 04:37:42 PM »
To enhance security, as regards to logins and passwords, this forum may migrate to HTTPS, TLS, or other.

Status: certificate acquired. site also works in http and https. Feel free to opine in this topic.

The original impetus was pushed by Google:
Nonsecure Collection of Passwords will trigger warnings in Chrome 56 for

To: owner of

Beginning in January 2017, Chrome (version 56 and later) will mark pages that collect passwords or credit card details as “Not Secure” unless the pages are served over HTTPS.

The following URLs include input fields for passwords or credit card details that will trigger the new Chrome warning. Review these examples to see where these warnings will appear, and so you can take action to help protect users’ data. The list is not exhaustive.

Here’s how to fix this problem:

Use HTTPS pages to collect sensitive information

To prevent the “Not Secure” notification from appearing when Chrome users visit your site, move collection of password and credit card input fields to pages served using the HTTPS protocol.

This means users visiting non HTTPS sites will see "Not Secure" in the address bar.

However converting to new URI prefix is not just changing the address. It's a complex process of acquiring SSL certificates and heavy modification to forum code and database to make sure all links are directed properly. It may also have issues with image sources not from other HTTPS sites.

Furthermore is the opinion that the HTTPS itself segregates the internet. Which makes HTTPS less backward compatible. And do most of the web need to be encrypted? Such as this tiny site in the remote recesses of the internet.

Moreover is the delay as the security certs are verified. That means every page will have a second or more of delay before the page is rendered to the user's browser. Which I find very annoying because it can't be prevented or diminished no matter how powerful your computer is.

So this a multi-pronged quandary. One, is it worth the hassle for this tiny site that all traffic be encrypted? For that matter, is it feasible to force millions of webmasters to comply to this authoritarian edict? Two, do we all agree that segregating the internet should be future? Could there be better, passive solutions than converting billions of links to HTTPS?

Vowel Ring for MOK (highly recommended)

Code: [Select]


and the generated URL to install the layout to the phone app:

attached screenshot.

spread vowels in a ring. (certain vowels too close can confuse word prediction, e.g. E/A)
common letters to the center or left of center. (right finger hides letters, so put uncommon letters at right edge.)

problems with MOK:
dictionary missing lots of words.
can't add new words to dictionary.
word prediction doesn't sort by user's frequency.
swiping long words is tedious.

Hacks / Re: X6.?H layouts
« on: March 07, 2017, 08:24:45 PM »
So I dunno ... not sure how "pleasant" it will be typing on these ... or if we need to relook at your scoring algo ...

I would think higher penalty for modifiers because they disrupt the flow. but in the end it doesn't make a difference since it would affect all layouts.

for that matter, using shift feels much better than double tapping caps lock.

Hacks / Re: Balanced Keyboard Layout
« on: March 07, 2017, 08:09:51 PM »
with a few modifications, excellent for English-Zhongwen (EZ):

Code: [Select]


see attachment for full layout.

for more radical approaches to slightly improve pinyin at expense of english:

Code: [Select]


Code: [Select]


apparently the vowel bigrams are improved for pinyin. in particular AU is now a roll rather than typed with the same finger. home row vowels are rearranged. H is moved to the consonant district. Y takes its place at the left pinky. G also interestingly moves to the vowel district at the index bottom. probably to raise hand alternation for tri- and quadgrams involving two vowels and NG.

unfortunately for the last two versions, the same finger rates are quite high.

so BEAKL EZ 1 the version recommended.

Hacks / Re: Balanced Keyboard Layout
« on: March 05, 2017, 06:23:31 PM »
I made a little modification for Chinese double pinyin and English writing , "J" "Z" back to base area and ";" "?" punctuation too, I hope these changes won't affect too much.

yea in consideration of pinyin, moving those letters in better places is great idea. one thing i would move Z to index bottom instead. but actually the Z on the left hand may not be wise. because you would be typing many 3 and 4-grams with the same hand. e.g. zhou, zhe, zou, zhai, etc. on the other hand, the right hand is full of consonants already. though you may consider moving K to the left hand and move Z to its old spot in the right pinky bottom.

consequently, in consideration of other languages and much time with the BEAKL, we should keep all the letters within the main 3x10 block. probably put parentheses at the outside, so I can still type them without any shifting.

Here's updated TEA ring for MOK.

Code: [Select]

and the generated URL to install the layout to the phone app:
Code: [Select]

attached screenshot.

the keys are not all the same size.
punctuation layer needs heavy modification.

need lots of time and trial and error to fix these issues (since i can't find any documentation on the syntax.)

I found the URL you can visit on your phone that lets you edit the layout and apply directly to the app:

I'm testing out Vowel Sandwich because that's the last layout I have that doesn't put the space in the middle, which would interfere with swiping. already can feel it's much better than qwerty and other flat, wide typewriter-based layouts.

Code: [Select]

and the generated URL to install the layout to the phone app:
Code: [Select]*()%E2%84%96%C3%B7%E2%88%9A%22%2C%0A%22~%60%7B%7D%5C%5C_-%3D%7C%2B%C2%A7%E2%88%B7%E2%80%A0%22%2C%0A%22%40%5B%5D%23%C2%B1%2F%C3%B7'%5C%22%C2%AB%C2%BB%E2%80%94%E2%80%A1%22%2C%0A%22%5BSHIFT%5D%E2%80%A6%3C%3E!%3B%3A%3F%E2%80%B9%E2%80%BA.%2C%5BDEL%5D%22%2C%0A%22%5BLOCK%5D%5BALTGR%3A%2C%5D%5BSPACE%5D%5B%5D%5B%5D%5BSYM%3A.%5D%5BENTER%5D%22%0A%5D%2C%0A%0A%22altGr%22%3A%5B%0A%22%5C%22%C2%AF%60%CB%87%C2%B4%C2%A8%CB%99%CB%9A%C2%B8%EF%B9%90%CB%9B%CB%98%CB%9C%CB%86%22%2C%0A%22%E2%80%95%E2%88%91%C3%A9%C9%99%C2%AE%E2%80%A0%CE%A9%C5%93%C3%B8%CF%80%E2%80%A2%C2%B7%22%2C%0A%22%C3%A6%C3%9F%E2%88%82%C3%B0%C6%92%C2%A9%C2%AA%C2%BA%E2%88%86%E2%89%A0%C4%B8%E2%88%9E%22%2C%0A%22%5BSHIFT%5D%CA%92%CE%A9%E2%89%88%C3%A7%C3%BE%E2%88%AB%C5%8B%C2%B5%E2%89%A4%E2%89%A5%5BDEL%5D%22%2C%0A%22%5BLOCK%5D%5BALTGR%3A%2C%5D%5BSPACE%5D%5B%5D%5B%5D%5BSYM%3A.%5D%5BENTER%5D%22%0A%5D%2C%0A%0A%22num%22%3A%5B%0A%22%5BSpace%5D123%5BDel%5D%22%2C%0A%22*456%23%22%2C%0A%22%2B789-%22%2C%0A%22%5BLock%5D%2C0.%5BEnter%5D%22%0A%5D%0A%7D%0A%7D%0A

attached screenshot.

(maybe later try again with updated TEA ring, which is more hexagonal.)

Thanks for suggesting multi long o. It seems great potential. Finally a swiping keyboard that lets you customize layout.

For any thumb layout, it's more ergonomic and efficient to be as round as possible. Not flat and long. especially true for swiping, else you're wasting energy traversing great distances across the entire screen for every word. It gets tiresome like immediately.

Thus I suggest more rows, about 5. Shorten columns to about 7.

Btw where are instructions to make own layout and theme?

Hacks / Re: Flownetic
« on: January 31, 2017, 04:33:51 PM »

1. are there official punctuation symbols?

2. your /s/ and 5 are rather close ... please advise?

Thanks, Ian

1. not yet.

2. they're same for now. you could make slight modifications to 5, like a hard stop at the left before continuing the stroke.

Hacks / Re: Balanced Keyboard Layout
« on: January 13, 2017, 01:02:22 AM »
So I go walkabout to see where you got the 45° figure from ... in my previous readings the figures I've seen for tenting were usually much lower, and typically similar to the rotation for the two halves of a split design (ie around 15°, or say 10° to 20°).

45 is just my observation when I put my hands at rest on the table, and which is just comfortable enough when tapping my thumbs (against air). this seems the best compromise and comfort for two different factors: wrist pronation and gravity.


I'm interested to use the BEAKL layout on a Planck keyboard.

Because I like the control key on the left and right pinky I moved some keys around.
How can I test this layout in the keyboard analyzer?


First, H should be on the pinky and A on the index home.

Here's a refined layout. I removed redundant keys.

Code: [Select]
* ,-----------------------------------------------------------------------------------------.
 * | J      |   Q  |   Y  |   O  |   U  |   X  |   F  |   G  |   R  |   C  |   V  |  Z       |
 * |--------+------+------+------+------+-------------+------+------+------+------+----------|
 * |Ctrl/Esc|   H  |   I  |E/FN5 |A/FN2 |   .  |   L  |   S  |   T  |   N  |   W  |Ctrl/Enter|
 * |--------+------+------+------+------+------|------+------+------+------+------+----------|
 * |Shift/( |   '  |   "  |   \  |   ,  |   /  |   B  |   D  |   M  |   P  |   K  |Shift/)   |
 * |--------+------+------+------+------+------+------+------+------+------+------+----------|
 * | Tab    | GUI  | Alt  | Hyper| Del  |    Space    | Bksp | Left | Down |  Up  |Right     |
 * `-----------------------------------------------------------------------------------------'

Hacks / Re: Balanced Keyboard Layout
« on: December 30, 2016, 09:57:50 PM »
there have been attempts to put the thumb keys on a vertical plane. however i don't think it works as good as you imagine.

the thumb hitting inwards towards the palm works best when it's countering the movement or grip of the other fingers or palm. that's why it's called the opposable thumb, to oppose the action of the hand and fingers. it works great such as for ergonomic mice because the mouse is held down by the hand. this provides resistance for the thumb to press against. on the other hand, an independent thumb that strikes orthogonally to the direction of gravity loses much of its effectiveness by using more effort.

then there are issues with technical and aesthetic designs you must overcome.

the main thing to get right is the tenting angle. if the keyboard tents about 40 to 45 degrees, then have the thumb keys 90 degrees of that. so the thumbs strike not totally perpendicular to the direction of gravity, but like 45 to 50 degrees.

Arts, Literature, and Crafts / Re: [lang] Flownetic: The Phonetic Script
« on: December 19, 2016, 01:11:30 PM »
Language convertor seems to produce same results regardless of input... same image as you posted.

Was trying to check up on image for 13, in your main Flownetic page is kinda like a backward P like the /p/ in Monofon, but glyph I have is basically a 3. Did you change it?

converter image has a static URL, but content will update when new text is entered.

decimal 13 should look like our 3.

Hacks / Re: PanGalactic Keyboard Layout
« on: December 19, 2016, 12:56:55 PM »
I would do vowels then consonants, and go down the columns left to right as presented in my tables.

Hacks / Re: PanGalactic Keyboard Layout
« on: December 18, 2016, 08:19:33 AM »
is 8 a Z or not-equals?

thanks, Ian

Two parallel horizontal lines connected by an oblique line connected at opposite ends of them. In short like a Z.

The latest official versions are found on this website.

Hacks / Re: PanGalactic Keyboard Layout
« on: December 15, 2016, 03:17:59 AM »
We can agree that we don't need more than one case.

Since we're talking about universal alphabet, we should go from general to specific, rather than singling out English. Some efficiency may be lost when typing in English or any given language.

How many keys do we need? Let's take Flownetic as work study, as that is the closest to IPA's ideal of one sound, one glyph.

Assume standard keyboard for typing text has 3 rows and 32 keys. We may use up to 4 layers: normal, shift, altgr, and shift+altgr.

Flownetic has (up to now) 83 glyphs. Let's further divide them so that the layers are more logical. Such that shifting a vowel key also spits out a vowel, not a consonant, and vice versa. So we have 35 vowels and 48 consonants in Flownetic.

Depending on the amount of layers we want to use:
2 layers: 18 v + 24 c = 42 keys needed
3 layers: 12 v + 16 c = 28 keys needed
4 layers: 9 v + 12 c = 21 keys needed

So in the best case, we need 3 layers to fit all Flownetic glyphs on a standard keyboard of 3 rows and 32 keys. I think 4 layers would be cumbersome. 3 layers still leaves 4 keys for punctuation.

The next dilemma is deciding the which glyphs go on which layer. Ideally the normal layer has the basic vowels and consonants commonly found across the most ubiquitous languages in the world.

Now discuss English for a moment. It is fortunate that most English sounds are basic and simple and also found in many other languages. That means for the most part, typing English would not be greatly adversely affected. There may be cases where normal key doesn't give a sound found in a given language. Would then have to shift and altgr, but we are already used to that due to capitalization.

Arts, Literature, and Crafts / Re: [lang] Li-Ya-Hu
« on: December 13, 2016, 04:43:48 AM »
Liyhau True-type font file

Symbolspacefull stopcommaliyahu
ASCIIspace ( )full stop (.)comma (,)Liyahu (%)

Code: [Select]

Fis is riten in liyahu %.

Code: [Select]

thalisispacelisispaceralitulenaspacelinaspaceluliyiyahahuspaceliyahufull stop

Hacks / Re: PanGalactic Keyboard Layout
« on: December 13, 2016, 03:52:22 AM »
i thought about creating a font for Flownetic, but never got around to do it. i did complete the Liyahu font at . For Flownetic there are more uncertainties that i've been mulling over.

Magic: the Gathering / Color Pie Distribution
« on: December 12, 2016, 07:31:14 AM »
Color Pie Distribution of New and Old Mechanics and Effects

Magic: the Gathering / Re: Mechanics
« on: December 12, 2016, 07:26:54 AM »
Disabilty (This object's abilities can't be activated or triggered.)

Hacks / Re: PanGalactic Keyboard Layout
« on: December 03, 2016, 05:36:33 AM »
Alphabets are phonemic systems, which means one letter correlates to one sound. For optimal simplicity, consistency, and cross-lingual coverage, then there should be certain ideal criteria for global standard alphabet.

1. One letter for one basic phone.
2. Eliminate redundancies.
3. Optimal coverage of phones within a comfortable amount of letters.

Since Latin alphabet is the de facto alphabet used across the globe, it would be easiest to modify that rather than try to have people adopt an entirely new glyph set. (But if that is a prerogative, check out my Flownetic alphabet, which is uniquely featural and phonetic and simple to write and read.)

It's obvious to anyone that Latin alphabet has quite a few redundant consonants, but also shortage of vowel sounds. Without increasing the set of symbols to learn, one may suggest turning redundant consonants into more vowels. That will in turn increase the possible combinations of vowel groups for all languages and avoid extraneous diacritics.

Then there are some common basic consonants that deserve their own letter. Such as Th, Ng, Sh, Ts, etc. I think we can safely expand the Latin alphabet to accommodate these.

The J in English is actually a compound sound which can be represented as DZ. (In the link you gave, it uses the proper Dʒ.) By the same token, Ch is more like TSh, where Sh would be given its own letter.

IPA has their own guidelines which are not necessarily (read: rarely) compatible with an everyday alphabet.

Hacks / Re: Balanced Keyboard Layout
« on: November 26, 2016, 06:19:25 AM »
So I was thinking .... (always a dangerous thing... )

What if we reintroduced some letters.... the thorn for th? The bigram et is not so common, and hi will often bump into th, but the next most common is "in" ... could not find a character with the dot on the left vertical of the n, but there is an n with a centre dot.

So then we could write, for example, "thin" as þṅ if that shows up correctly in your browser....

Point being that we reduce 2 very common bigrams down from 2 letters to 1 letter, and improve efficiency in that way....

The & is already too well known to use as-in but there is a turned version ⅋.

I'll shut up now... :-)

Cheers, Ian
Sometimes IPA chars show up if you put them inside the code tags.

TH and NG should have their own letters, as they are basic sounds and very common in many languages.

J should have the English Y sound, like it is in Scandinavian languages. Then Y has the IPA
Code: [Select]
/ʉ/ (middle u) (as in Uber) (can be used in place of /ʊ/, as in book, and /y/ found in e.g. Mandarin and Cantonese)

Replace QXC with three more vowels. Such as these:
Code: [Select]
IPA sounds:

/ə/ (schwa)
/ɔ/ (short o)
/ɐ/ (short u)

Schwa is neutral sound, and so can be used to approximate other similar sounds. The last two are quite common by themselves, but also commonly used in diphthongs.

Altogether, the nine vowels cover nine distinct sections of the vowel chart as described in IPA. As such, they can better approximate more sounds across all languages.

Hacks / Re: BEAKL Opted4 Ergo Alt
« on: November 26, 2016, 05:27:14 AM »
I've also got some other variants to test, so I'll wait for your fix, then I can test them all at the same time. That's still going to be a lot of copy-pasting but at least not typing numbers off the screen.

Then I need to modify Patrick's code and do it all again with his scoring....

Cheers, Ian

Completed BEAKL Opted4 Ergo Alt. I moved a lot of puncs around.

And since you mentioned that 94 chars would not fit 31 keys, I messed around with Opt again. This time using exactly 32 keys symmetrically. Also tweaked the settings to see if I can force N back onto the home row. I saw a few layouts it spit out had the W on the pinky. This reduces pinky usage and same-pinky penalty even more. The drawback is high same-finger usage, especially on the right index. The puncs on AltGr mainly derived from Arensito as a base. In short, this is the best BEAKL so far by far for both prose and code.

Introducing BEAKL5 ErgoLinear:

Code: [Select]

  '"),( BDMPK

I updated my KLA page with these two layouts (the first two layouts you'll see).

Hacks / Re: % efficiency
« on: November 22, 2016, 01:21:33 PM »
The scoring algorithm already does something similar. The penalty score is exra effort over a baseline. The baseline is number of characters times minimum effort to hit a (home) key (not taking into account finger weight. The baseline may vary if that layout is missing characters.

I'm not sure efficiency 100% or greater makes sense in context. It's like saying an object can move faster than the speed of light.

Hacks / Re: BEAKL Opted4 Ergo Alt
« on: November 22, 2016, 12:54:01 PM »

BEAKL Opted4 Ergo Alt is missing @ ... please advise :-)

94 glyphs need more than 31 keys :-)

thanks, Ian

i'ma rework it to fit it in

Magic: the Gathering / Re: Online Card Creator
« on: November 07, 2016, 08:01:34 PM »
  • Added Full Art frame

Hacks / Re: Balanced Keyboard Layout
« on: November 05, 2016, 10:19:29 PM »

Stumbled across this today, thought you may find it interesting. Would have been more fun optimising the keyboard with three extra letters... :-)

alphabets across the world need more vowel letters. pathetic that we mix up 5 vowels to make up 30+ vowel sounds. makes transliteration between languages very cryptic and confusing. OTOH we have redundant consonants like Q and C and X.

Magic: the Gathering / Re: Online Card Creator
« on: November 05, 2016, 03:48:07 PM »
  • Added energy mana. Use 'e' in mana cost or {e} in rules text.
  • Allow set icon and rarity. (not done for all frames yet.)
  • Use imagick instead of gd. (not done for all frames yet.)
  • Better help section.

Hacks / Re: Balanced Keyboard Layout
« on: November 05, 2016, 12:51:02 PM »
There's some theory that "sticky keys" for modifiers are healthier than holding and releasing them. This is the style that supertypist Sean Wrona uses. He uses CapsLock instead of shift (unless typing punctuation.)

My proposal is to turn ScrollLock into NumPunc sticky key. First because US keyboards usually don't have AltGr anyway. So I need something common on most keyboards (at least logically). This is separate from NumLock which I use to initiate a ten-key purely for fast numeric entry.

Second this is very easily programmed in autohotkey on Windows, and probably Xorg on Linux as well.

Third as the initial pargraph suggests, this is ergonomic. Especially if one types long strings of puncs, as one might when coding. Then you don't have to hold down AltGr for long periods of time.

Hacks / Re: Balanced Keyboard Layout
« on: November 05, 2016, 01:59:30 AM »
As lazy typist, bottom row feels better and faster. The top row requires slight movement of entire arm to reach. Whereas bottom row can be typed simply by curling the fingers.

I'll test some adjustment to effort grid and see if Opt gives different layout. Sometimes changes to these values have no impact on optimal layout. I'll make bottom ring finger more favorable than top ring finger. Likewise, bottom inside index preferred over than top inside index. Overall weight of layout will tend toward bottom row to facilitate my lazy style.

Hacks / Re: Balanced Keyboard Layout
« on: November 02, 2016, 03:07:23 AM »
Xah wanted a universal layout that can be used efficiently everywhere in the world.

It's not that difficult when you consider that BEAKL already scores so well in English, French, German, and Pinyin. (You can get corpus of various languages by browsing wikipedia in different languages. I got Pinyin corpus from lyrics of Chinese songs.)

Accented letters can be served with AltGr tailored to each language.

Hacks / Re: Balanced Keyboard Layout
« on: November 02, 2016, 02:29:41 AM »
I corrected PPC for ergolinear back to match Standard: 26.315789. This should improve scores for ergolinear layouts.

AdNW of course is pretty good, since it belongs to the current reigning family of layouts: HIEA-STR.

Actually OA/AO is not common at all: a mere 0.05%. OE/EO together is 0.04%.

Xah had an idea to find the best the layout that incorporates all the common languages of the world. including English, Chinese, European, etc. That could be interesting. From isolated informal testing, HIEA-STR tend to do very well across most languages. Probably due to Dvorak's breakthrough idea to split the keyboard into vowel and consonant districts, which is easily adaptable and efficient due to nature of spelling in most languages.

Hacks / Re: Balanced Keyboard Layout
« on: October 30, 2016, 06:17:55 AM »
I think when I was playing around I first tried the standard code (and that pixels/cm), then swopped out the bottom part for the ergo code because that allowed me to specify the gap between the keys. I still don't understand how your code works to create the gap... it seems almost like it's building it from the outsides in :-)

The layout is symmetrical, so split the loop in half. The offset for left-half is obvious due to coordinates system. Zero starts at the left and top. So left-half rows all start at zero + any border offset.

Then the reverse is true for right-half: right-half rows all align at the right edge = max width. For computational efficiency inside the loop (simplest math operation is addition) find the leftmost offset of the current row in the right-half, then build the remaining keys left to right.

Hacks / Re: Balanced Keyboard Layout
« on: October 30, 2016, 03:50:33 AM »
I see the pixels/cm are different. That is curious.. should they not be all the same?

KB.keyMap.standard.s683_225.pixelsPerCm = 26.315789;
KB.keyMap.european.s683_225.pixelsPerCm = 26.315789;
KB.keyMap.ergodox.s683_225.pixelsPerCm = 25.7894732;//26.315789;

Think I will ask Patrick about that....

And then you set
KB.keyMap.ergolinear.s683_225.pixelsPerCm = 25.315789;

Was that a typo or did you mean 25 not 26?

I looked at difference between standard and ergodox and thought that wider layout should have lower PPC. But actually dont understand their relationships. We need to delve deeper.

Hacks / Re: Balanced Keyboard Layout
« on: October 29, 2016, 05:13:20 PM »
the pixelsPerCm might not be accurate on my map. if you use the same value as Standard, the scores improve a bit.

the gap between keys shouldn't matter. it's the total distance between keys. e.g. the default normKeySize is 50 and no gap = 50. but i can make the  normKeySize 48 and gap 2 = 50 still. the total distance remains the same.

Hacks / Re: Balanced Keyboard Layout
« on: October 29, 2016, 12:27:48 PM »
Trust you didn't change the scoring? :-)

Not that i remember. Havent touched in a while.

Hacks / Re: Balanced Keyboard Layout
« on: October 29, 2016, 02:24:36 AM »
it was put together quickly to test new layout. not worried about that prototype's score. nevertheless it does show some tiny improvement. probably bigger effect on worse layouts. (mainly due to thumb modifiers.)

Hacks / Re: Balanced Keyboard Layout
« on: October 28, 2016, 10:07:08 PM »
Updated my analyzer

try it out and send me your layouts to be uploaded

see images

Hacks / Re: Balanced Keyboard Layout
« on: October 28, 2016, 08:46:02 PM »
better to copy from Standard layout. it's much simpler, doesn't involve rotation. then erase anything to do with variable key width.

Hacks / Re: Balanced Keyboard Layout
« on: October 28, 2016, 06:41:53 PM »
don't forget the KB.glyphLayouts part at the top of kb.js

Hacks / Re: Balanced Keyboard Layout
« on: October 28, 2016, 06:15:30 PM »
a minor change that would be very helpful is to print the "Space" on the keyboard. 

add this at end of
Code: [Select]
KB.Key.labels[32] = "Space";

you might as well fill out the bottom row. for extra keys, like arrows and page control.

Hacks / Re: Balanced Keyboard Layout
« on: October 26, 2016, 01:45:03 PM »
Yeah I was just looking at that page now... printed our the ErgoDox part to use as a template. Have you been able to figure out what the s683_225 means here:

KB.keyMap.standard.s683_225 = {};
KB.keyMap.standard.s683_225.width = 754;//756
KB.keyMap.standard.s683_225.height = 252;//254

KB.keyMap.ergodox.s683_225 = {};
KB.keyMap.ergodox.s683_225.width = 935;
KB.keyMap.ergodox.s683_225.height = 360;

The 935 and 360 are on-screen pixel dimensions, etc. Maybe the numbers were from a previous version that he tweaked? eg 745 -> 683, 252 -> 225 ?

It's some hardcoded figure. Not sure what it means, but just use the same name for compatibility.

Pages: [1] 2 3 4 ... 18