2018年03月19日

同時打鍵の打鍵負担率を可視化する

私はこんな説明をしてきました。

さらに同時打鍵系が厄介なのは、たとえば Nicola では、実質打鍵数 28 キー分の負荷を、名目打鍵数の 17 ストロークで負担しなければならないこと。

実質打鍵数の計算は連続シフトを考慮していませんが、飛鳥カナ配列が名目打鍵数101,156ストロークを入力する時間で、実質打鍵数151,837キー分の押下負荷を担わなければならないことは、連続シフトの有無に関わらず同じです。

分かる人はこんな説明でも分かってくれるからいいとして、分からない人は何のことやらさっぱりだろうと、書いた当初からずっとモヤモヤしてきました。今さらですが、補足説明を試みます。可視化するターゲットは さっぽろでちーむにごうりゅうした。 をちょっと変えた、さっぽろでちーむにごうりゅうする。 の17字。

関連記事

利き手と左右別の打鍵頻度の関係を再考する
2014-11-10
「同時打鍵」は魔法の呪文ではない。
2011-02-12

札幌でチームに合流する。

まずは同時打鍵しない qwerty ローマ字入力から紐解きます。表の縦軸は strokes を単位とした時間を、横軸は keys を単位とした負担を表します。

qwerty ローマ字配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
s S 1
A 1
p P 1
P 1
O 1
r R 1
O 1
d D 1
E 1
t T 1
I 1
- 1
m M 1
U 1
n N 1
I 1
g G 1
O 1
U 1
r R 1
y Y 1
りゅ U 1
U 1
s S 1
U 1
r R 1
U 1
1
28 10 18 28
  • 実質打鍵数 28 keys / 名目打鍵数 28 strokes = 打鍵負担率 1.00
  • 実質打鍵数 30 keys / 入力文字数 17字 = 打鍵効率 1.76
  • 交互打鍵数 13 strokes / 名目打鍵数 28 strokes = 交互打鍵率 0.46

同時打鍵が発生しないので、28ストロークを打鍵する時間で28キーを負担しています。除した数値=打鍵負担率は 28/28=1 となります。

Nicola 配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
T 1
2
L 2
C 2
D 2
U 1
X 2
2
U 2
R 2
A 1
E 2
F 2
A 1
C 1
I 2
Q 1
17 5 11 6 6 28
  • 実質打鍵数 28 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.65
  • 実質打鍵数 28 keys / 入力文字数 17字 = 打鍵効率 1.65
  • 交互打鍵数 8 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.47

元祖親指シフトは、17ストロークを打鍵する時間で28キーを負担しています。打鍵負担率、打鍵効率とも同時打鍵系ではワースト。16:12で左手の打鍵が多く、左手側で6連打が発生しています。

新下駄配列
strokes 左手側 右手側 Keys
シフト 文字 文字 シフト
S L 2
G 1
S 2
V L 2
1
T 1
Q 1
V K 2
W 1
W K 2
J 1
りゅ Q O 2
J 1
Z 1
V 1
1
16 1 11 5 5 22
  • 実質打鍵数 22 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.38
  • 実質打鍵数 22 keys / 入力文字数 17字 = 打鍵効率 1.29
  • 交互打鍵数 3 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.19

打鍵負担率、打鍵効率ともベスト。12:10で左手側がやや多く、左手5連打が1回、左手4連打が1回発生しています。

蜂蜜小梅配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
F 2
N 1
D 2
V 1
E 2
2
H 1
H 2
O 1
A 2
M 1
りゅ W L 2
M 1
1
F 1
Q 1
16 3 6 10 4 23
  • 実質打鍵数 23 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.44
  • 実質打鍵数 23 keys / 入力文字数 17字 = 打鍵効率 1.35
  • 交互打鍵数 5 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.31

「ぽ」を[Z右]で入力しても、左:右=9:14で、左手3連打が1回発生することに変わりありません。打鍵効率は次点。

飛鳥かな配列 123
strokes 左手側 右手側 Keys
シフト 文字 文字 シフト
/ 1
M 1
P 1
2
2
X 1
W 1
N 2
C 1
@ 2
D 1
V 1
1
D 1
K 2
J 2
2
17 4 6 11 3 24
  • 実質打鍵数 24 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.41
  • 実質打鍵数 24 keys / 入力文字数 17字 = 打鍵効率 1.41
  • 交互打鍵数 8 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.47

打鍵負担率は次点。シフト側で[▼]と表した箇所では連続シフトが効いていますが、シフトキーを押しっぱなしにできても、実質打鍵数2の状態が続くのは変わらず、打鍵負担率を改善する効果はありません。左:右=10:14。

Tron 配列
strokes 左手側 右手側 Keys
シフト 文字 文字 シフト
V 1
/ 1
T 2
2
P 2
F 2
J 2
K 2
O 2
C 1
E 2
K 1
X 1
D 2
K 1
N 1
W 1
1
18 2 8 10 7 27
  • 実質打鍵数 27 keys / 名目打鍵数 18 strokes = 打鍵負担率 1.50
  • 実質打鍵数 27 keys / 入力文字数 17字 = 打鍵効率 1.59
  • 交互打鍵数 11 strokes / 名目打鍵数 18 strokes = 交互打鍵率 0.61

オリジナル Tron 配列は同時打鍵ではないらしいので、この文例も親指キー押しっぱなしで入力しようと思えばできるはず。ですが、右親指キー押しっぱなしで[.][P]の運指なんて、[P]嫌いの私には拷問としか思えません。左:右=10:17。

薙刀配列 v4
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
U 2
G 1
Z L 2
A 2
E J 2
G 2
1
R 2
D 2
V J 2
L 1
りゅ E 2
L 1
O 1
I 1
N 2
16 2 9 7 8 26
  • 実質打鍵数 26 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.63
  • 実質打鍵数 26 keys / 入力文字数 17字 = 打鍵効率 1.53
  • 交互打鍵数 3 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.19

最大3キー同時打鍵で親指1シフトという薙刀配列の、できたて v4 を採り上げます。 親指キー同時シフトは他手シフト、という前提で計算しています。叢雲配列に似てるのかと思いきやシフトの使い方が正反対で、無理やりに例えれば Tron + 下駄 + 蜂蜜小梅 1.4.2+00 という感じですかね。左:右=11:15で、 連続シフトが1回、 左手側で親指キーを含めた6連打が1回、3連打が1回発生しています。

これで十分だと思いますが、

もう一つ、「これで十分だと思いますが、」で打鍵負担率を可視化します。各配列が工夫を凝らした「これ」「おもい」「ますが、」の運指をお楽しみください。

qwerty ローマ字配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
k K 1
O 1
r R 1
E 1
d D 1
E 1
j J 1
じゅ U 1
U 1
b B 1
U 1
n N 1
N 1
d D 1
A 1
t T 1
O 1
O 1
m M 1
O 1
I 1
m M 1
A 1
s S 1
U 1
g G 1
A 1
1
28 12 16 28
  • 実質打鍵数 28 keys / 名目打鍵数 28 strokes = 打鍵負担率 1.00
  • 実質打鍵数 28 keys / 入力文字数 17字 = 打鍵効率 1.64
  • 交互打鍵数 10 strokes / 名目打鍵数 28 strokes = 交互打鍵率 0.36

左手側で4連打が発生しています。

Nicola 配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
R 1
T 2
D 2
S 2
D 2
A 1
V 2
1
E 2
J 1
J 2
G 2
L 1
O 2
C 1
W 2
@ 1
17 3 11 6 7 27
  • 実質打鍵数 27 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.59
  • 実質打鍵数 27 keys / 入力文字数 17字 = 打鍵効率 1.59
  • 交互打鍵数 7 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.41

左:右=14:11 でやはり左が多く、左手側で7連打が発生しています。

文字キーの運指だけ拾います。

これ
RT
ますが
OCW

くそみたいな運指も含めて qwerty ローマ字配列と五十歩百歩。溜め息しか出ません。

新下駄配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
I 1
D K 2
1
じゅ W O 2
J 1
/ 1
F 1
S M 2
S 1
D L 2
F K 2
K 1
X 1
Z 1
O 1
R 1
16 1 9 7 4 21
  • 実質打鍵数 21 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.31
  • 実質打鍵数 21 keys / 入力文字数 17字 = 打鍵効率 1.24
  • 交互打鍵数 4 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.25

実質打鍵数21はさすが。左:右=10:11でほぼ拮抗。左手側で5連打が発生しています。

蜂蜜小梅配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
A 1
J 2
D 2
じゅ X L 2
M 1
C 2
J 1
S 2
1
U 1
D 2
K 1
C 1
1
D 2
@ 1
16 2 7 9 5 23
  • 実質打鍵数 23 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.44
  • 実質打鍵数 23 keys / 入力文字数 17字 = 打鍵効率 1.35
  • 交互打鍵数 12 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.75

左:右=9:14。打鍵効率は次点。こういう平面図で俯瞰すると、蜂蜜小梅配列と Tron 配列は本当によく似ています。

飛鳥かな配列 123
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
L 2
E 2
2
Z 1
1
D 1
B 1
J 1
A 2
I 1
S 2
2
K 1
L 2
K 2
D 2
2
17 6 7 10 4 27
  • 実質打鍵数 27 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.59
  • 実質打鍵数 27 keys / 入力文字数 17字 = 打鍵効率 1.59
  • 交互打鍵数 12 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.71

左:右=13:14。連続シフトが5回発生しています。「が」が左手側に押しやられてしまったのは、やっぱり美しくない。

Tron 配列
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
E 1
P 1
F 2
L 2
D 2
K 1
G 2
1
A 2
S 1
H 2
G 1
J 1
Z 1
N 1
D 2
1
17 2 9 8 5 24
  • 実質打鍵数 24 keys / 名目打鍵数 17 strokes = 打鍵負担率 1.41
  • 実質打鍵数 24 keys / 入力文字数 17字 = 打鍵効率 1.41
  • 交互打鍵数 15 strokes / 名目打鍵数 17 strokes = 交互打鍵率 0.88

左:右=11:13。打鍵負担率は次点。

薙刀配列 v4
strokes 左手側 右手側 keys
シフト 文字 文字 シフト
V 1
S 1
E J 2
じゅ R J, 3
L 1
F 3 2
1
F N 2
D 1
M 2
K 2
K 1
F 2
O 1
F J 2
V 2
16 5 4 8 8 6 27 26
  • 実質打鍵数 27 26 keys / 名目打鍵数 16 strokes = 打鍵負担率 1.69 1.63
  • 実質打鍵数 27 26 keys / 入力文字数 17字 = 打鍵効率 1.59 1.53
  • 交互打鍵数 3 strokes / 名目打鍵数 16 strokes = 交互打鍵率 0.19

左:右=13:14 12:14。打鍵負担率はワースト。左手4連打が1回、連続シフトが1回発生しています。

「ぶ」の[親F.]はまだしも、「じゅ」の[RJ,]って、とっさに打鍵できます?

親指同時シフトを省略した[F.]で「ぶ」が入力できるとご教授いただきました。数値を訂正しました。

まとめ

ワーストケースとベストケース、わずか2つの文例ですが、各配列の強烈な個性が見えてきますね。手前味噌にもなりますが、飛鳥、新下駄、蜂蜜小梅の3配列は、どんな局面でも安定した性能を発揮できているように思えます。

本稿では打鍵負担率という指標を新たに用いましたが、既出の同時打鍵率や無シフト率とほぼ同じものです。下記に違いを記しておきます。

打鍵負担率
実質打鍵数 / 名目打鍵数
同時打鍵率
実質打鍵数 / 名目打鍵数 − 1
無シフト率(実質打鍵数ベース)=単打率
1 − (実質打鍵数 / 名目打鍵数 − 1)

3キー以上の同時打鍵では計算式が異なります。

参考までに、10万字サンプルにおける同時打鍵率を再掲します。薙刀配列はまだ計算してません。


打鍵効率 (keys/字) 同時打鍵率
Nicola 配列 1.422 42.2%
Tron 2005-1011 1.251 25.1%
飛鳥カナ配列 1.501 50.1%
蜂蜜小梅配列(タイプ・アシスト利用なし) 1.317 35.1%
蜂蜜小梅配列(タイプ・アシスト利用あり) 1.303 33.6%
新下駄配列 1.262 29.5%
Qwertyローマ字配列 1.747 0.0%
最大3キーの同時打鍵って、どっかで見たことがある

そして薙刀配列は、今までの "俺様配列" とは異なる文脈・違う尺度で作られた日本語配列のように感じます。

薙刀配列が採用した「最大3キー同時打鍵の両手清濁拗同置」は、シフトの掛け方こそ異なりますが、蜂蜜小梅配列が生まれるきっかけとなったアイディア そのものです。しかし、言うは易く行うは難し。

蜂蜜マトリックスを捨てて当初の蜂蜜小梅配列に戻してくれと頼まれても、現在の私は即座に却下します。そもそもが物理キーではなく論理キーで日本語を入力しているのですから、拗音入力時だけ盤面をマトリックスに切り替えても、「し」と「ょ」の同時打鍵で「しょ」を入力する感覚は変わりません。だったら私は、指遣いが圧倒的に楽な蜂蜜マトリックスを選びます。

メリットの裏にはデメリットが必ずあります。叩き込んだ目の前の釘は、反対側に飛び出します。パーフェクトな人間なんて存在しないのと同様、パーフェクトな日本語配列もまた存在しません。譲れない性能と消し去りたい欠点の狭間に、工夫と妥協の結果として、蜂蜜小梅配列もまたあります。

蜂蜜小梅配列が叩き込んだ目の前の釘は、反対側に飛び出て薙刀配列になった。そんな気さえしてくるのは、春霞のせいでしょうか。

posted by 141F at 01:09| Comment(2) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年02月22日

脳内発声あり

親指シフトはカナ入力じゃないのかよ。ってなツッコミはさておき。

親指シフトです。既述の通り、脳内発声バリバリです。打鍵速度は脳内発声に律せられます。高校の数 III で理系人生に終止符を打ちましたが何か。

脳内発声なしで思考するってどういう状態? と、しばらく途方に暮れましたが、例えば出掛ける前に道順や乗り換えを探っている時は、路線図や断片的な風景なんかを思い浮かべていて、言葉には頼っていません。(論理的に)思考している時も、ちょっと歯切れが悪くなりますが、脳内発声していないように思います。

言葉として出力する時は、例外なく「脳内発声あり」です。qwerty ローマ字だと「かんんにんんぐ」みたいに脳内発声しまくりで、頭が疲れます。

脳内発声の有無によって、適した日本語配列が異なるという論旨は理解できますが、その分け方が違うように思えます。直感的に。親指シフトはカナ入力じゃないのかよ、と。

ラベル:親指シフト
posted by 141F at 01:59| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年02月18日

小梅配列+蜂蜜マトリックス≠蜂蜜小梅配列

一滴から始まった違和感がいつしか拭い切れなくなってきたので、冬季オリンピックが始まったタイミングで決着をつけます。蜂蜜小梅配列と小梅配列の関係性を再確認します。

一般的には「親指シフトの小梅配列」と、「拗音拡張を追加した蜂蜜小梅配列」てな感じで認識されているものと思われますが、それだけではないんです。あるいは、蜂蜜小梅配列のほか、シンプルな小梅配列もある――などと説明される場合もありますが、ちょっと待てと言いたい。

2つの日本語配列の関係性を紐解くならば、どちらも俺の、俺による、俺のための俺様配列=同じもの=です。性能や成熟度といったパラメータこそ異なりますが、蜂蜜小梅配列が「小梅配列との上位互換性」を捨てた瞬間から、2者の時間軸は継承・連続していることをまずは強調しておきます。

蜂蜜小梅配列のカナと記号が、キー別・シフト別にどの時点で確定したか、最終更新時期=最終確定時期をまとめた下図をご覧ください。赤く塗られた「5」の部分が、蜂蜜小梅配列を名乗った 2.0.0版 ⇒ 2.5.6 版の時期に進化した部分です。全部で33エリアありました。[D×K]の「を」を含めると35エリアが、小梅配列から蜂蜜マトリックス以外で成長しているのです。

キー毎に時計回りで無シフト、右シフト、左シフトを表記しています。例えば「N」キーでは、無シフト「っ」が実用版時点に確定、同様に右シフト「み」が投了版時点、左シフト「ぇ」は 最終版時点に確定しています。

蜂蜜小梅配列のカナと記号の最終更新時期""

蜂蜜小梅配列に脱皮する最終フェーズで何をやっていたかというと、

  • 日本語配列としての安全性を高める
  • 低頻度カナ対策を充実させる
  • 記号の配置を見直す
  • 無シフト率を高める

といった課題に、思考実験の積み重ねで対応していました。

我が輩はカエルである

関係性をオタマジャクシとカエルにたとえてみましょうか。2者は見た目も名前も異なりますが、どちらも同じ生き物(幼体と成体)なのはご存知の通り。親指シフトという沼で暮らしていた小梅配列に、いつしか蜂蜜マトリックスという手足が生えて、さらに35カ所が変態してカエルとなった蜂蜜小梅配列は、陸をピョンピョンと自由に飛び跳ねています。

未熟なオタマジャクシを他人様に推奨するというオプションは、少なくとも作成者の私にはありえません。

「だけでも」から始めよ

蜂蜜小梅配列で「だけでも」は[S右][W左][E右][D左]。

タイプアシストを使うと[WE][SD]。

これを覚える「だけでも」全然違います!

ラベル:蜂蜜小梅配列
posted by 141F at 00:24| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2018年01月17日

涙雨

キミの初恋の人がバイトしているという喫茶店に二人で出かけて、一緒にそわそわしていた光景を、懐かしく思い出します。

ドライブが好きなキミと、うまいもんを食いに行ったり、ひなびた温泉に泊まったり、完徹で初日の出を拝みに行ったり、ホントにいろんなところに出かけたよね。

そういや、鶴見線に乗りに行って、海芝浦駅でぼんやりしたした。思い出は尽きません。

キミは忘れてしまったかもだけど、二人の生まれ故郷・盛岡で、一緒に岩山に登ろうっていう約束は、果たせないままになってしまいました。

晩秋の檜枝岐で

中学時代からの盟友K君は、若き日の喜怒哀楽を分かち合い、大人になってからもよく遊んだ、かけがえのないよき友でした。屈託ないキミの笑顔がもう見られないなんて、未だに信じられません。いくらなんでも早すぎるよ。

今日はキミの四十九日。千葉の遠いこの街も、涙雨に濡れています。どうか安らかにお眠りください。

posted by 141F at 23:28| Comment(0) | various | このブログの読者になる | 更新情報をチェックする

2018年01月15日

デスクトップオーディオ 2017+

堅くて重い集成材をカットして、アンプとスピーカーの下に敷きました。スパイクを板にぶすりと直刺ししたら、同軸 2way ユニットがほぼ耳の高さまでかさ上げされて、一石二鳥でいい感じです。

下に集成材を敷いたTeac AI-503とKef IQ30

関連記事

デスクトップオーディオ 2017
2017-10-29
(続)デスクトップオーディオ増強計画(余)
2013-07-22
ラベル:PC audio
posted by 141F at 01:00| Comment(0) | audio visual | このブログの読者になる | 更新情報をチェックする

2018年01月03日

謹賀新年 2018

明けましておめでとうございます。千葉では雲一つない快晴の三が日となりました。

輝ける樹木

穏やかな一年でありますように。本年も万事ゆるめでお付き合いください。

posted by 141F at 22:46| Comment(0) | various | このブログの読者になる | 更新情報をチェックする

2017年12月25日

CSipSimple で使う @niftyフォン-C

CSipSimple で @niftyフォン-C を使うための覚え書き。

ウィザードを選択 > Advanced

アカウント名
任意(@nifty-phone とか)
発信者番号
050????????
@niftyから割当済の050電話番号
サーバ
nifty.com
@niftyから割当済のSIP-URL(SIPドメイン名)
ユーザ名
050????????
発信者番号と同じ
SIP認証ID
@niftyから割当済のVoIPユーザID
パスワード
@niftyから割当済のVoIPユーザパスワード
TCPを使用(UDPを使わない)
チェックしない
プロキシ
voip??.nifty.com
@niftyから割当済のVoIPサーバ名

NAT通過

これも設定しといた方がいいかも。

STUNを有効
チェックする
STUNサーバ
s1.taraba.net

コーデックの指定等は今後の課題。

posted by 141F at 23:23| Comment(0) | gear | このブログの読者になる | 更新情報をチェックする

2017年11月10日

「かえうち」を導入した(4)

お待たせしました。「かえうち」用の蜂蜜小梅配列カスタマイズファイルを公開します。

蜂蜜小梅配列「かえうち」カスタマイズファイル@141F ver.

当初、シフトの掛かり方に難ありの状態です と記しましたが、シフトが期待通りに掛からなかったのは、「かえうち」の同時打鍵ロジックそのものに原因がありました。

2種類の打鍵方式

画像化して、見たままのスタイルで引用します。

蜂蜜小梅配列のハイブリッド同時打鍵は、上記引用の「ながら押し」に該当します。

  • 先に[★]キーを打鍵して、次に[☆]キーを打鍵する
  • 先に[☆]キーを打鍵して、次に[★]キーを打鍵する

上記パターン各々に別の機能を割り当てられるのは何だか便利そうですが、「同時打鍵」したい私にとってこれ以上の迷惑はありません。キーボード入力における「同時打鍵」は、厳密に言えばキーを「同時に打鍵している」のではありません。

  • [★]⇒[☆]の打鍵
  • [☆]⇒[★]の打鍵

どちらも等しく「同時打鍵」です!

私の場合は[文字]キーが先になる[親指]キー同時打鍵がわりと多いみたいで、[親指]キーに[文字]キーを同時打鍵したパターンしか定義していなかったので、見事にシフトが掛からなくなっていました(注)。

[★]⇒[☆]の定義だけして、[☆]⇒[★]と打鍵していたら、シフトが掛かるはずもなく。

ということで、

「ながら押し」ではなく「同時押し」に設定するには

いささか冗長ですが、マニュアル通りに双方向で定義することで、シフトが確実に掛かるようになりました。

本日の不具合(再掲)

  • 濁点「゛」、半濁点「゜」の単独入力ができない⇒「う゛」なんていう表現がキーボードだけでは難しい。
  • 各種括弧を使い分けて定義しても、期待通りに入力できない。
  • かえうちパートナーを起動していると、カギ括弧ペア「」の入力が「』に化ける。
  • ctrl-k+s 等の2ストロークキーコマンド(^ks と表記)が実行不能。

これらはすべて「仕様」とします。このうち、1番目は「かえうち」の仕様、3番目はかえうちパートナー for Windows の既知の不具合とマニュアルに記載がありました。4番目の2ストロークキーコマンドは、ctrlキーを押したまま[K][S]と順に押すことで無事に実行できました。

かえうちでの蜂蜜小梅配列の使い方

  • [ひらがな]キーでオン
  • [半角/全角]キーでオフ

かえうちを使ってみて

ストアアプリでも蜂蜜小梅配列で入力できてしまうのって、とっても不思議な面持ちになりますね。ただし、「かえうち」を使えば万事解決してオールハッピーかといえば、さにあらず。現状で最大の不満は、なしてすぐ off になる?

ブラウザを見てエディタに戻ると勝手に off になる。ブラウザでフォーカスを隣のタブに移すと勝手に off になる。それどころか、検索窓に入力して検索した瞬間、勝手に off になる。なして? なして? なして?

明示的に off にしない限り、ずっと on のままでいられる設定って、どこかにないのでしょうか。

最後に、素晴らしい未来をご提供いただき、本当に感謝しています。ありがとうございました>うぇぶしまさん。

posted by 141F at 01:43| Comment(1) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年11月08日

「かえうち」を導入した(3)

本日の進展。

  • 記号の類を実装した。
  • 小指シフト面を実装した。
  • ctrl-c や ctrl-v 、shift+space 等のキーボードオペレーションが支障なく行えるようになった。

本日の不具合。

  • 濁点「゛」、半濁点「゜」の単独入力ができない⇒「う゛」なんていう表現がキーボードだけでは難しい。
  • 各種括弧を使い分けて定義しても、期待通りに入力できない。
  • かえうちパートナーを起動していると、カギ括弧ペア「」の入力が「』に化ける。
  • ctrl-k+s 等の2ストロークキーコマンド(^ks と表記)が実行不能。

これらの不具合については、最悪の場合「仕様」扱いでこのままリリースするかもしれません。悪しからずご了承ください。

posted by 141F at 02:46| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする

2017年11月07日

「かえうち」を導入した(2)

今夜は「かえうち」で入力しています。

シフトが掛からない原因が、どうやら特定できたようです。とりあえずの対策を施したので、あとは試し打ちでバグをつぶしがてら、微調整を加えていきます。

記号がまだ完全に実装できていないので、そこはきちんと対応します。それから、ctrl-c や ctrl-v、shift+space 等のキーボードオペレーションに副作用が出ているので、もう少し勉強しないとダメみたい。

posted by 141F at 00:41| Comment(0) | oyayubi | このブログの読者になる | 更新情報をチェックする