Glfw: 選択の増分転送のサポートを追加します

作成日 2014年04月15日  ·  5コメント  ·  ソース: glfw/glfw

あなたがでこれをREPROできるクリップボードアプリ、ここでのフォルダのテストから26214 バイトのジャンクファイルは、それのすべてをコピーして、ウィンドウに貼り付ける、あなたが得られます。

Error: X11: Failed to convert selection to string
Clipboard does not contain a string
X11 bug verified

最も参考になるコメント

私はこれを自分で調べていましたが、実装を完了することができませんでした。 うまくいけば、それを実装しようとした経験の一部が、同じことをしようとしている他の誰かに役立つかもしれません。 一言で言えば、これが何が起こり、ICCCMがこのINCRアトムを処理するために私たちに何を期待するかです:

以下では、 _glfwPlatformGetClipboardString呼び出すと、X11が非常に悲しくなります。

if (_glfwGetWindowPropertyX11(event.xselection.requestor,
                              event.xselection.property,
                              event.xselection.target,
                              (unsigned char**) &data))
    _glfw.x11.clipboardString = strdup(data);

その理由は、タイプUTF8_STRING event.xselection.targetを要求しているためです。これは、選択所有者の最大許容シングルバッチ転送サイズ(262146バイトこの場合)。 選択の所有者ではなく、私たちに与えるだろうactualTypeINCR要求された型と同じではありませんこれはUTF8_STRING 。 所有者は、データを段階的に送信したいと考えていUTF8_STRINGを含むいくつかのXGetWindowPropertyのチャンクで送信します。

これを解決するには、ICCCMの推奨事項「INCRプロパティ」に従う必要があります。 しかし、一言で言えば:

  1. XInternAtomを使用してINCR -atomへのハンドルを取得します(例: INCR_STRING
  2. INCR_STRING actualTypeを受け取ったかどうか、 _glfwGetWindowPropertyX11参照してください。受け取った場合は、次のようになります。
    a) XGetWindowPropertyを使用してINCR_STRINGをフェッチします。これには、転送の下限が含まれています。
    b)このINCR_STRINGプロパティを削除して、所有者が良いものを送ってくれるようにします。
    c) PropertyNotifyイベントを待ち、完全なデータのチャンクの到着を通知します。
    d) XGetWindowPropertyを使用してチャンクデータを取得し、バッファに追加します。
    e)プロパティを削除し、所有者に追加のチャンクを送信するように通知します。
    f)cにループバックしない場合は、データのサイズがゼロかどうかを確認します。
    g)転送が完了しました。これで、データ全体が完成しました。

興味があれば、これが私が書いたインクリメンタルセレクションの半分完了した実装の要点です。
問題を調査するときに役立つと思ったリンクをいくつか示します。

うまくいけば、これは誰かの役に立つでしょう、残念ながら私はそれを自分で理解することができませんでした。

全てのコメント5件

GLFWは、インクリメンタルクリップボードデータ転送をまだサポートしていません。

自己メモ: UTF8_STRING

私はこれを自分で調べていましたが、実装を完了することができませんでした。 うまくいけば、それを実装しようとした経験の一部が、同じことをしようとしている他の誰かに役立つかもしれません。 一言で言えば、これが何が起こり、ICCCMがこのINCRアトムを処理するために私たちに何を期待するかです:

以下では、 _glfwPlatformGetClipboardString呼び出すと、X11が非常に悲しくなります。

if (_glfwGetWindowPropertyX11(event.xselection.requestor,
                              event.xselection.property,
                              event.xselection.target,
                              (unsigned char**) &data))
    _glfw.x11.clipboardString = strdup(data);

その理由は、タイプUTF8_STRING event.xselection.targetを要求しているためです。これは、選択所有者の最大許容シングルバッチ転送サイズ(262146バイトこの場合)。 選択の所有者ではなく、私たちに与えるだろうactualTypeINCR要求された型と同じではありませんこれはUTF8_STRING 。 所有者は、データを段階的に送信したいと考えていUTF8_STRINGを含むいくつかのXGetWindowPropertyのチャンクで送信します。

これを解決するには、ICCCMの推奨事項「INCRプロパティ」に従う必要があります。 しかし、一言で言えば:

  1. XInternAtomを使用してINCR -atomへのハンドルを取得します(例: INCR_STRING
  2. INCR_STRING actualTypeを受け取ったかどうか、 _glfwGetWindowPropertyX11参照してください。受け取った場合は、次のようになります。
    a) XGetWindowPropertyを使用してINCR_STRINGをフェッチします。これには、転送の下限が含まれています。
    b)このINCR_STRINGプロパティを削除して、所有者が良いものを送ってくれるようにします。
    c) PropertyNotifyイベントを待ち、完全なデータのチャンクの到着を通知します。
    d) XGetWindowPropertyを使用してチャンクデータを取得し、バッファに追加します。
    e)プロパティを削除し、所有者に追加のチャンクを送信するように通知します。
    f)cにループバックしない場合は、データのサイズがゼロかどうかを確認します。
    g)転送が完了しました。これで、データ全体が完成しました。

興味があれば、これが私が書いたインクリメンタルセレクションの半分完了した実装の要点です。
問題を調査するときに役立つと思ったリンクをいくつか示します。

うまくいけば、これは誰かの役に立つでしょう、残念ながら私はそれを自分で理解することができませんでした。

ありがとう、それは素晴らしい説明です! 他のプラットフォームでのいくつかの関数呼び出しであるものを達成するためにクライアントが行う必要があることは少しばかげています。

私は2日前にINCRの実装を開始しました。 私は読み取り作業とSTRING / Latin-1からの変換を行っていますが、INCR、MULTIPLE、およびSTRINGを組み合わせて書き込みできることに気付いたとき、少し絶望しました。 それがきれいに実行される前に、いくつかの再構築が必要です。

誰かが覗き見したい場合は、今すぐselection-fixesブランチにプッシュしました。

しばらくの間、プルリクエストのレビューに集中する必要があります。 私は恥ずべき時間の間、たくさんのすばらしいコードを待っていました。 上記のコードに基づいているかどうかにかかわらず、当面の間、誰かがこれに取り組み続けたい場合は、そうしてください。

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