Xterm.js: 부드러운 스크롤

확실히 할 수는 있지만 소수의 사람들이 사용할 수 있는 작업에는 많은 작업(+복잡성 추가)이 필요합니다. 나는 이것을 개인적으로 추가하지 않는 것이 좋습니다.

그것은 이해할 수 있고 공정합니다. 작업해주셔서 감사합니다!

참고: VTE(GNOME 터미널 및 친구들) 는 버전 0.44부터

아주 소수의 사람들이 사용하는 것

터치패드로 스크롤하는 분들은 좋든 싫든 VTE에서 사용합니다. :D

@egmontkob 여기에 gnome 터미널 3.18.3이 있는데 작동하지 않는 것 같습니다. 프로필 설정의 스크롤 섹션에도 설정이 없는 것

gt 3.18.3은 vte 0.42가 있음을 의미하는 반면 이 기능은 0.44의 새로운 기능입니다.

새로운 설정이 없으며(하나를 추가하기 위해 보류 중인 낮은 우선순위 요청 이 있음) 이전과 다르게 작동합니다.

누군가 이미 VTE에서 구성할 수 없는 것에 대해 불만을 표명했습니다. 물론 xtermjs에서 이 기능을 구현할지 여부와 구현하는 경우 구성할 수 있는지 여부는 전적으로 귀하의 선택입니다.

이 기능이 VTE에 1.5년 이상 존재했으며 트랙패드를 사용하는 모든 VTE 사용자에게 (마우스 휠이 스크롤의 "단위"를 보내는 대신에) "강제적으로" 존재했다는 것이 귀하에게 귀중한 데이터 포인트가 될 수 있다고 생각합니다. 우리는 여전히 전체 줄을 스크롤합니다), 그리고 이 시간 동안 나는 이전 행동을 되살리기 위해 총 2~3개의 불만을 들었습니다. 이 기능이 형편없었다면 불만이 훨씬 더 많았을 것입니다.

VTE에 대한 사용 횟수나 비율이 없습니다. 가장 가까운 것은 이 설문 조사 의 결과입니다(기사 날짜는 주석의 타임스탬프를 기반으로 하여 수정됨, 2년 된 투표임). 이는 VTE가 Linux 터미널 에뮬레이터 사이의 시장 점유율은 50%, 즉 꽤 큽니다. 그래서 많은 사람들이 이미 부드러운 스크롤링을 사용하고 있습니다.

저는 xtermjs 및 친구가 처음이고 아직 시도하지 않았습니다. 여기서 멋진 일이 일어나고 있다는 것을 알 수 있습니다. 내 마음에 올바른 아키텍처가 있는지 확신할 수 없지만 그렇게 한다면 GNOME 터미널은 VTE에 대한 hterm이 xtermjs에 대한 것입니다. VTE는 터미널 에뮬레이션을 수행하는 GTK+ 위젯입니다. GNOME Terminal, Xfce4 Terminal, Terminator, Tilix를 포함하여 VTE를 사용하는 12개 정도의 인기 있는 터미널 에뮬레이터 앱이 있습니다.

동작을 시도하려는 경우 가장 쉬운 방법(및 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 행 수를 그리고 현재 스크롤 위치의 픽셀 오프셋을 기반으로 첫 번째 행과 두 번째 행 사이 어딘가에서 오프셋하는 것처럼 간단해야 합니다.

확실히 할 수는 있지만 소수의 사람들이 사용할 수 있는 작업에는 많은 작업(+복잡성 추가)이 필요합니다. 나는 이것을 개인적으로 추가하지 않는 것이 좋습니다.

Fwiw 나는 같은 기능을 요청하려고했습니다. 개인적으로 사용성을 높이는 중요한 단계라고 생각합니다. 더 광범위하게 지원되지 않는다는 사실은 상대적으로 새로운 아이디어이고 우리 프로그래머는 작업해야 하는 제한 사항에 익숙해지는 경향이 있다는 사실로 설명할 수 있습니다.

왜 안 돼?

@sdegutis 네, 가능합니다. 그 당시에는 캔버스 렌더러가 필요한 콘텐츠 섹션만 무효화하는 특수 로직을 사용하여 고도로 최적화될 것이라고 생각했습니다. 이제 캔버스 렌더러로 터미널을 스크롤하면 어쨌든 모든 행이 다시 렌더링되며 기본 계획은 어쨌든 캔버스 렌더러를 단계적으로 제거하는 것입니다.

이 작업을 수행하는 것은 꽤 쉬울 것입니다. 3개의 렌더러에 대해 수행해야 하며 특히 webgl에는 몇 가지 특별한 조정이 필요합니다(행 * 열보다 더 많은 셀이 그려지기 때문에 속성 버퍼의 크기 증가).

나는 또한 이 기능을 좋아합니다. 제 문제는 실제로 단순한 미학이 아니라 사용성 문제입니다. 문제는 한 가지 작업으로 인해 터미널에서 너무 많은 건너뛰기가 발생하고 부드러운 스크롤이 없다는 사실로 인해 건너뛴 줄을 이해하는 것이 거의 불가능하다는 것입니다. 정말 터미널을 사용하기 어렵게 만듭니다.

Visual Studio Code에서 터미널을 스크롤할 때마다 내가 어디에 있었는지 추적하지 못합니다. 부드러운 스크롤은 기본 기능이며 우리에게 필요합니다.