Archiveこの広告は、90日以上更新していないブログに表示しています。いう特殊なキーコードを用意している。キーと「無変換」を一つのキーに収容するといったことができる。キーを押してから離す操作を非常に素早く行うと、レイヤーの切り替えがうまく行われずに誤入力が発生する問題がある。関数に手を加えることで解決できる。この方法はあぷろさんに教えて頂いたのだが、知見を共有する意味で記事として残しておくことにしたい。具体的な実装例は本文の最後に掲載する。オンを「変換」キーに割り当てるようにしている。キーボードにおける「かな」キーや「英数」キーと同じであり、ホームポジションに置いた親指で操作できるのでアクセスしやすい。「半角/全角」キーと違って、現在の入力モードが英語なのか日本語なのかを気にせずに所望のモードへ確実に切り替えることができる。次期バージョンではこのキーアサインを既定にすることも検討されている。blogs.windows.com僕にとっては、この「確実に切り替えられる」という点が重要で、プログラムを書いたりコマンドを打ち始める前に、とりあえず無変換キーを連打するクセがついてしまっているほどだ。そのようなわけで、自作キーボードにおいても「無変換」と「変換」をなるべく親指でアクセスしやすい位置に置いておきたいという要求がある。二つのレイヤー切り替えキーが重要な役割を果たす。組み合わせで入力するようになっているので、これらもなるべく親指付近に置いておきたい。その他にも親指で操作したいキーにはスペースやエンターなどもあるわけで、親指でアクセスしやすい一等地である↓の辺りはいよいよ混み合ってくる。親指クラスタところが、親指という指は一般に考えられているほど器用ではないし、可動域もさほどではない。個人的には、親指で使いこなせるキーはせいぜい三つで、理想的には二つに抑えたいという感じがする。使いたいキーが三つあるなら、うち二つのキーを一つの物理キーに収容して使い分けたくなる。キーの押され方をファームウェアで識別すれば二つのキーを一つの物理キーで扱えるんじゃないか、というアイディアにたどり着く。いう特殊なキーコードが用意されている。KC_HENK)...しない。これ、動くには動くのだが、おそらく多くの人間が期待していない動作をする。オンも働いてしまい、とても残念なことになる。押して一呼吸おいてから文字の入力を始める、というような人間側のワークアラウンドが必要で、とてもストレスフルだ。いう定数で決まっているので、これを小さく設定すれば問題は軽減するが根本的な解決ではない。以内に離さないと入力が失敗するといったことが起きる。コントリビュータの人からも話を聞けたのだが、結論としては「あまりいい解決策はない」ということになってしまった。設計の根幹に関わる問題*1なので、残念ながら当分は改善されないと思われる。作ったのを機に「本格的にどうにかせねばなぁ」という機運が高まってきた。ファームウェアに詳しい人たちに相談したところ、あっさりと解決してしまった。最初から聞いておけば...。配列の設定を工夫しても解決しない。スレでも軽く言及されている)。以下のようなデフォルト実装が書かれていると思う。いう関数の説明はこの辺にある。ここでは関係ないので無視してよい)。キーを押して離した際の挙動をカスタマイズする。true;}ポイントとしては以下のような感じ。置いておくので、もしよければご参考までに。は細かいカスタマイズをしようとすると途端に難しくなる場合が多い(これを非プログラマの人にやってもらうのはなかなか厳しい)。この辺りが、「新しい自作キーボードファームウェアを作りたい」という話が出てくる一つの動機になっている。チャンネルでは、この辺りの話題について議論が交わされているので、興味のある人は覗いてみてほしい。他の方法について指摘を頂いたので紹介させて頂きたい。有用そうなのでいずれ試してみたい。自分もタップで変換、ホールドで別キーやりたくて実装してたけど、特にノウハウをまとめてなかった...。使わないので、MACRO_TAP_HOLD_LAYERを利用してて、keymap.cを作る際には必須。認知度が低いのか、使ってるkeymap.cが皆無なんだよね。キーマトリクスの走査結果をバッファせず、直接イベントハンドラをコールバックするアーキテクチャになっており、前後のキー入力イベントに依存して出力を変えるのが難しい。さんの「Chainerで確率分布が扱えるようになりました。chainer.distributionsの紹介」でした。つけるために色々と試行錯誤をしている。オートコンプリートが機能するようにしたいと考えている。ライブラリに型を付けるにあたってのノウハウ的な話を共有したい。そのため、例えば、ある関数に渡した変数が正しい型であるかは実行してみるまで分からない。オートコンプリートがうまく働かないという問題があった。型ヒントと呼ばれる機能が導入された。属性に格納する以外には何もしない。この機能は実行時に型検査を行うためのものではない。サードパーティの静的型検査器を使う。コードを検査して型の整合性を確認する。mypy-lang.orgあるいは、関数アノテーションではなくコメントで書いてもよい(型コメント)。始まるコメントを認識して、関連付けられた式の型を判断する。系でも動作するコードになるというメリットがある。サポートしているので、今回はこちらの記法を使うことになる。typing.get_type_hints(f){}ユーザは、組み込み型以外にも自前で型を定義できる。単純なエイリアスだけでなく、ジェネリクスのような高度な型にも対応している。クラスのインスタンスなので、新しい型を定義する際はコード中に直接書けばよい。以前でも問題なく実行できる。定義した型は、通常の実行時にはインスタンス化されるだけで使われない。484(日本語訳)を参照してほしい。仕様とは言っても分かりやすく書かれているので、静的型付き言語のユーザならば馴染みのある話が多いし簡単に読めると思う。既存のコードベースへの組み込む際の設定方法については、このドキュメントが参考になった。以降でないとインストールすらできないという点。含む各バージョンのテストを回しているライブラリでは、下記のようにチェックしてやる必要がある。Type)既存の動的型付き言語のライブラリに型ヒントをつける際の課題として、ある関数の引数に渡される値が様々な型を取りうる、という点が挙げられる。アノテーションで型ごとにシグネチャを宣言してもよいが、これだと複雑な組み合わせへの対応が大変になる。いう特別な型を提供している。含まれていればどの型が渡されても正しい式として扱う。両方の場合がありえる。使うことで、このような型もエンコードできる。渡されることを許容する関数のシグネチャを書く時に使う。渡すとエラーを出してくれるので便利。メソッドを実装しているので、あたかも関数であるかのように呼び出すことができる。引数に取る普通の関数を渡しても動作する。呼んでいるだけだからだ。この挙動は通常は便利なのだが、今回のように型をつけようとすると問題になる。すると型が合わないからだ。