Glfw: 押されたmodを持つ文字に対して常に呼び出される修飾子を使用した文字コールバック

作成日 2020年01月04日  ·  4コメント  ·  ソース: glfw/glfw

やあ、

  • 最初にここで説明しました: https
  • GLFWバージョン:3.3(Ubuntu 19.10)

現在、入力されたすべての文字の修飾子を使用して文字イベントを受信することはできません。

私のデモは次のとおりです。ユーザーが標準(en_US)キーボードレイアウトでCtrl+[を入力すると、キーとcharコールバックで問題なく動作しますが、(たとえば)de_DE(German [y])キーボードレイアウトを使用すると、次に、 Ctrl=[を送信するために、ユーザーが押す必要があるのはCtrl+AltGr+8です。 これは、キーコールバックによってCtrl+Alt+8 (ユーザーアプリ自体がキーボードレイアウトマッピングを再実装するべきではなく、ユーザーがどのキーボードマッピングを持っているかわからないため、役に立ちません)、さらに重要なことに、文字コールバックとしてキャプチャされます。そのために呼び出されることはなく、そのために呼び出される修飾子付きのcharacter-with-modifierコールバックもありません。

私の要求は基本的に、character-with-modsコールバックに、すべての修飾子を使用して入力されているすべての文字について知らせることです-このコールバックがen_US以外のキーボードレイアウトで呼び出されないこともバグのように感じます(私のテストケース:de_DE)なので、実際にバグなのか機能リクエストなのかわかりません。

ps: glfwSetCharModsCallbackが非推奨になる理由を説明するリソースが見つかりませんでした。 これが私が使用するのに意味のある唯一の関数のようです(現在、完全には機能していませんが)。 多分誰かがこの決定のためにどこを見るべきか知っていますか?

よろしくお願いします。
キリスト教徒。

input

最も参考になるコメント

glfwSetCharCallbackわかります。

基本的に、 CTRL+ALT+8などのキーを押しても文字は生成されないため、glfwSetCharCallbackやglfwCharCallbackは呼び出されません。 これは、GLFWがそれを削除するために何かをしているためではなく、このキーの組み合わせを表す文字が存在しないためです。

ただし、キーの組み合わせALT+8は文字を表し、例のキーボードレイアウトでは[です。

したがって、フォーラムで提案した解決策は、修飾キーが存在する場合に翻訳を処理できるように、glfwGetKeyNameを拡張する必要があるということです。 したがって、新しいバージョンは次のようになります。

const char* glfwGetKeyName ( int key, int scancode, int mods );

glfwはCTRLmodを無視する必要があるか、APIのユーザーはmodとしてのCTRLが文字を生成しないことを知る必要があることに注意してください。 私は後者の方がより明白であると思います。

全てのコメント4件

glfwSetCharCallbackわかります。

基本的に、 CTRL+ALT+8などのキーを押しても文字は生成されないため、glfwSetCharCallbackやglfwCharCallbackは呼び出されません。 これは、GLFWがそれを削除するために何かをしているためではなく、このキーの組み合わせを表す文字が存在しないためです。

ただし、キーの組み合わせALT+8は文字を表し、例のキーボードレイアウトでは[です。

したがって、フォーラムで提案した解決策は、修飾キーが存在する場合に翻訳を処理できるように、glfwGetKeyNameを拡張する必要があるということです。 したがって、新しいバージョンは次のようになります。

const char* glfwGetKeyName ( int key, int scancode, int mods );

glfwはCTRLmodを無視する必要があるか、APIのユーザーはmodとしてのCTRLが文字を生成しないことを知る必要があることに注意してください。 私は後者の方がより明白であると思います。

明確にしてくれてありがとう。

信じられないかもしれませんが、OpenGLを使用してC ++ターミナルエミュレーターでも作業していて、まったく同じ問題に直面しています。 実際には、 https://github.com/zokrezyl/ascitermの下で作業をC ++に移植しています。

回避策はありますか? ところで。 @christianparpartは、オープンソースの実装を計画している場合は、設計アプローチについて喜んでチャットします。

編集: @christianparpartこれがソースコードだと思います: https

ねえ@zokrezyl

それはすごいですね。詳細が必要な場合は、私にメールするのが最善だと思います。 おしゃべりさせていただきます。 ... [email protected]は、あなたが私に連絡する方法です。

しかし、glfwに関して。 キティは独自のフォークを維持していて、私はちょうどQtGuiに移植しました。 そして正直、後悔はしていません。 :)

メールでお会いしましょう、
キリスト教徒。

このページは役に立ちましたか?
0 / 5 - 0 評価