Xterm.js: スムーズなスクロール

作成日 2017年12月11日  ·  16コメント  ·  ソース: xtermjs/xterm.js

CLIを初めて使用する人として、他のほとんどのアプリケーションのスムーズなスクロールとは対照的に、端末で使用される行スクロールで行を表示するのは認知的に難しいと感じています。 ターミナルでは、ピクセルではなく文字が最小のディスプレイユニットであるためだということを学びました。

xterm.jsがこれを回避し、スムーズなピクセルベースのスクロールオプションを組み込むことは可能(そして望ましい)ですか?

私はもともと@albinekbにHyper(https://github.com/zeit/hyper)について同じことを尋ね

aremouse-support typenhancement

最も参考になるコメント

非常に少数の人が使用するもの

タッチパッドでスクロールする人は誰でも、好きかどうかにかかわらず、VTEでそれを使用します:D

全てのコメント16件

確かにそれは可能ですが、非常に少数の人が使用するものでは、かなりの作業(+複雑さの追加)が必要になります。 これを個人的に追加したくない。

それは理解できて公平です。 あなたの仕事をありがとう!

参考:VTE(GNOMEターミナルとその仲間)バージョン0.44以降ます。 (もちろん、ターミナルエミュレータのスクロールバックでのみ機能し、テキストエディタでファイルをスクロールする場合は機能しません。)

非常に少数の人が使用するもの

タッチパッドでスクロールする人は誰でも、好きかどうかにかかわらず、VTEでそれを使用します:D

@egmontkobここにgnometerminal 3.18.3がありますが、機能していないようです。プロファイル設定のスクロールセクションにも設定がないようです。

screen shot 2017-12-18 at 6 57 19 am

gt 3.18.3は、vte 0.42を使用している可能性が高いのに対し、この機能は0.44の新機能です。

新しい設定はありません(追加するための保留中の低優先度のリクエストがあります)。以前とは異なる動作をします。

誰かがすでにこれがVTEで構成できないことについて嫌悪感を表明しました。 もちろん、この機能をxtermjsに実装するかどうか、また実装する場合は構成可能にするかどうかは、完全に選択できます。

この機能がVTEに1。5年以上存在し、(スクロールの「ユニット」を送信するマウスホイールではなく)トラックパッドを使用するすべてのVTEユーザーに「強制」されていることは、貴重なデータポイントになると思います。そのため、私たちはまだ行全体をスクロールします)、そしてこれらの時間の間に、私は古い振る舞いを取り戻すために合計で2つまたはおそらく3つの苦情を聞きました。 この機能がうまくいかない場合は、さらに多くの苦情があります。


私はVTEについての使用数や比率を持っていません。私が持っている最も近いのは、この投票の結果です(コメントのタイムスタンプに基づいて、記事の日付が変更されていることに注意してください。


私はxtermjsとその友達に不慣れで、まだ試していません。ここでクールなことが起こっているのを見てください。 自分の頭の中に正しいアーキテクチャがあるかどうかはわかりませんが、そうすると、GNOMEターミナルはVTEに対して、htermはxtermjsに対してです。 VTEは、ターミナルエミュレーションを行うGTK +ウィジェットです。 GNOMEターミナル、Xfce4ターミナル、ターミネーター、Tilixなど、VTEを使用したターミナルエミュレーターアプリは、多かれ少なかれ人気があります。


この動作を試してみたい場合、最も簡単な方法(このため、およびGNOMEターミナルからの協力を必要としないVTE機能)は、VTEのみをコンパイルしてテストアプリを起動することです。

  • gitまたはtarballから取得
  • ./autogen.sh (git)または./configure (tarball)
  • make
  • ./src/app/vte-2.91 (0.51から)または./src/testvte (最大0.50)または./bindings/vala/vte-2.91または./src/vte-2.91 (最大0.50、ある時点で別のディレクトリに移動されました)

私はマウスホイールを使用していました、それが私の問題です:sweat_smile:

最初の投稿で、私が実際にトラックパッドを使用しているという非常に重要な詳細について言及するのを忘れました。 トラックパッドのユーザーや他のタッチベースの入力方法のユーザーを無視すると、ピクセルベースのスクロールを好む人はほとんどいないことを理解しています。

IMOは、現時点でユーザーが期待していると言っても過言ではありません。 つまり、htermでさえそれを持っています。

キャンバスレンダラーでは実際には不可能ですが、キャンバスレンダラーを置き換えるwebglレンダラーhttps://github.com/xtermjs/xterm.js/pull/1790を使用するとかなり簡単に実行できるはずです。 DOMレンダラーの場合、上部と下部に部分的に見える線を配置することでこれを実現できます。 そのため、これは#1790でブロックされていると思います

他に考慮すべき点: ydispが整数ではなく、 Terminal.rows超える行が表示されていると、コードで行われたいくつかの仮定が破られます。たとえば、スクリーンリーダーのサポートにどのように影響しますか?

キャンバスレンダラーでは実際には不可能です

なぜだめですか? viewportHeight + 2の行数を描画し、現在のスクロール位置のピクセルオフセットに基づいて最初の行と2番目の行の間のどこかでオフセットするのと同じくらい簡単である必要があります。

確かにそれは可能ですが、非常に少数の人が使用するものでは、かなりの作業(+複雑さの追加)が必要になります。 これを個人的に追加したくない。

Fwiw同じ機能をリクエストするつもりでした。 個人的には、使いやすさを向上させるための重要なステップだと思います。 それがより広くサポートされていないという事実は、それが比較的新しいアイデアであり、私たちプログラマーは私たちが取り組まなければならない制限にただ慣れている傾向があるという事実によって説明することができます。

なぜだめですか?

@sdegutisええ、それは可能です。当時、キャンバスレンダラーは、それを必要とするコンテンツのセクションのみを無効にする特別なロジックを使用することで、高度に最適化されると考えていました。 キャンバスレンダラーでターミナルをスクロールすると、とにかくすべての行が再レンダリングされます。さらに、デフォルトではキャンバスレンダラーが段階的に廃止される予定です。

これを実行するのは非常に簡単です。3つのレンダラーに対して実行する必要があり、特にwebglには特別な調整が必要です(行*列よりも多くのセルが描画されるため、属性バッファーのサイズを大きくします)。

私もこの機能が大好きです。私の問題は実際には単なる美学ではなく、使いやすさの問題です。 問題は、1つのアクションによって、端末でスキップが多すぎることと、スムーズなスクロールがないために、どの行がスキップされたかを理解することがほとんど不可能になることです。 それは本当に端末を使いにくくします。

Visual Studio Codeでターミナルをスクロールするたびに、どこに行ったかがわかりません。 スムーズなスクロールは基本的な機能であり、私たちはそれを必要としています。

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

関連する問題

LB-J picture LB-J  ·  3コメント

jerch picture jerch  ·  3コメント

kolbe picture kolbe  ·  3コメント

circuitry2 picture circuitry2  ·  4コメント

albinekb picture albinekb  ·  4コメント