Qt key hell
初回投稿日時: 2010年06月11日01時36分28秒
カテゴリ: 雑談
固定リンク: id=2010061100
SNS:
(list)
Qtのソースコード拾ってきてみたところ、QKeyMapperPrivateというクラスがあって、これでキーコード、もしくはネイティブのキーイベントから入力されるテキストへと変換しているんですが、名前から分かるとおりAPIではありません(そもそもこのクラスのメソッドがXP化されていない)。
また、X11の場合はネイティブイベントを渡さないと処理できないようなので、何らかのAPIからキーイベントを生成して自分で受け取ってテキストを参照する、という手法も使えない様です。
このAPIの不備はスクリーンキーボードを作れないことを意味しています。Macでもさすがにこの辺の泥臭いAPIは用意してくれている(ちなみに10.4まではぼろぼろ)ので、Qtが持っていないのはまったくもって意外でした。GTK(GDK)はちゃんと持ってるんですけど。
X11を直接見に行く、しか手段がなさそうですね。私がやるわけではないんですが。
整形ぐらいツールでなんとかならんのか、って誰かtwitterで言ってたな、そういえば。まぁそういう考え方もあるかも。
誰の言葉か知りませんけど、非現実的というかそうとう鬱陶しい解決策ですね。
Mozillaの場合、超巨大な変更はツリーをクローズしてからランディングします。なぜかというと、理由は簡単、パッチ形式でのマージなので、どこか一カ所でもrejectされると駄目だからです。
もちろん、そんな超巨大パッチであれば他のパッチのrejectの原因にもなりますが、修正の手間が(分散する分)あまりたいしたことはありませんし、必要な修正なので手作業でのマージにも納得がいきます。
ですが、インデントの修正だけで現在作業中のパッチが軒並みrejectなんかされようものなら、怒号が飛び交うでしょう。それも、議論を尽くさずに長年のスタイルを変更してすぐに元に戻してるんですからなおさらです。
余談ですがGeckoはドキュメント化されていませんが、モジュール毎に独自のコーディングルールをもっていて、ツールで一括変更というのは実は出来ません。
ちなみに私があのコーディングスタイルが変だと思う理由は以下の可能性があるからです。
switch (...) {
case 1: {
// something
}
}
同じインデントレベルで閉じ括弧のみの行が重なるのはなんか気持ち悪いですし、switchで毎度こうなる訳でもないのがなんかアレですよね。
switch (...) {
case 1: {
// something
}
}
あとは、switchの前後とインデントレベルが一緒なので、switch全体が独立したブロックとして視認しにくかったですね、実際に書いてみると。
Something1(arg1);
Something2(arg1, arg2);
Something3(arg3);
switch (foo) {
case VK_A:
case VK_B:
case VK_C:
case VK_D:
case VK_E:
Someting4();
break;
case VK_F:{
PRBool dmy;
Something5(&dmy);
break;
}
default:
Something6();
break;
}
Someting7(arg4);
if (IsTrue()) {
Someting8(arg5, arg6);
}
Someting9();
空行入れれば見やすく……と思うかもしれませんが、実際には、caseブロックにも空行出現するかもしれませんので無意味です。これが現行ルールで書くと次のようになって一目でswitchブロックが分かるようになります。
Something1(arg1);
Something2(arg1, arg2);
Something3(arg3);
switch (foo) {
case VK_A:
case VK_B:
case VK_C:
case VK_D:
case VK_E:
Someting4();
break;
case VK_F:{
PRBool dmy;
Something5(&dmy);
break;
}
default:
Something6();
break;
}
Someting7(arg4);
if (IsTrue()) {
Someting8(arg5, arg6);
}
Someting9();