Xterm.js: Desplazamiento suave

Ciertamente es posible hacerlo, pero sería bastante trabajo (+ complejidad adicional) para algo que tan poca gente usaría. Preferiría no agregar esto personalmente.

Eso es comprensible y justo. ¡Gracias por tu trabajo!

FYI: VTE (Terminal GNOME y amigos) hace esto desde la versión 0.44. (Por supuesto, solo funciona en el desplazamiento hacia atrás del emulador de terminal, no cuando, por ejemplo, se desplaza por el archivo en un editor de texto).

algo que tan poca gente usaría

Todos los que se desplazan con el panel táctil lo usan en VTE, les guste o no: D

@egmontkob Tengo el terminal gnome 3.18.3 aquí y no parece funcionar, ¿la sección de desplazamiento en la configuración del perfil tampoco parece tener una configuración?

gt 3.18.3 lo más probable es que tenga vte 0.42, mientras que esta característica es nueva en 0.44.

No hay una nueva configuración (hay una solicitud pendiente de bajo precio para agregar una), simplemente se comporta de manera diferente que antes.

Alguien ya expresó su disgusto por que esto no sea configurable en VTE. Por supuesto, es totalmente su elección si implementa esta función en xtermjs, y si lo hace, si la hace configurable.

Creo que podría ser un dato valioso para usted que esta función haya estado en VTE durante más de 1,5 años y "forzada" a todos los usuarios de VTE que usan un panel táctil (en lugar de la rueda del mouse que envía "unidades" de desplazamiento para lo cual todavía nos desplazamos líneas enteras), y durante estos momentos escuché 2 o quizás 3 quejas en total para traer de vuelta el comportamiento anterior. Si esta característica apestaba, habría muchas más quejas.

No tengo números de uso o proporción sobre VTE, lo más cercano que tengo son los resultados de esta encuesta (tenga en cuenta que la fecha del artículo está alterada, según las marcas de tiempo de los comentarios, es un voto de 2 años) lo que sugiere que VTE La cuota de mercado entre los emuladores de terminal de Linux está en el estadio de béisbol del 50%, es decir, bastante grande. Así que mucha gente ya usa el desplazamiento suave.

Soy nuevo en xtermjs y mis amigos y aún no lo he probado, solo veo que están sucediendo cosas interesantes aquí. No estoy seguro de tener la arquitectura correcta en mente, pero si la tengo, GNOME Terminal es para VTE lo que hterm es para xtermjs. VTE es un widget GTK + que realiza emulación de terminal. Hay alrededor de una docena de aplicaciones de emulador de terminal más o menos populares que utilizan VTE, incluyendo GNOME Terminal, Xfce4 Terminal, Terminator, Tilix ...

En caso de que desee probar el comportamiento, la forma más fácil (para esto, así como para cualquier característica de VTE que no requiera la cooperación de GNOME Terminal) es compilar solo VTE e iniciar su aplicación de prueba:

• Obtener de git o tarball
• ./autogen.sh (git) o ./configure (tarball)
• make
• ./src/app/vte-2.91 (desde 0.51) o ./src/testvte (hasta 0.50) o ./bindings/vala/vte-2.91 o ./src/vte-2.91 (hasta 0.50, se movieron a otro directorio en algún momento)

Estaba usando la rueda del mouse, ese es mi problema: sweat_smile:

En la publicación inicial olvidé mencionar el detalle bastante importante de que uso un trackpad de hecho. Sin tener en cuenta a los usuarios de trackpad o los usuarios de otros métodos de entrada táctiles, entiendo que pocas personas prefieren el desplazamiento basado en píxeles.

En mi opinión, es seguro decir que los usuarios solo lo esperan en este momento. Quiero decir, incluso hterm lo tiene.

Realmente no es posible con el renderizador de lienzo, sin embargo, debería ser bastante fácil de lograr con el renderizador webgl https://github.com/xtermjs/xterm.js/pull/1790 que debería reemplazar al renderizador de lienzo. Para el renderizador DOM, podemos lograr esto al tener líneas parcialmente visibles en la parte superior e inferior. Como tal, considero que esto está bloqueado en # 1790

Algo más a considerar: tener ydisp no ser un número entero y tener más de filas visibles que Terminal.rows rompe algunas suposiciones hechas en el código, por ejemplo, ¿cómo afecta el soporte del lector de pantalla?

No es realmente posible con el renderizador de lienzo.

¿Por qué no? Debería ser tan simple como dibujar viewportHeight + 2 número de filas y compensar en algún lugar entre la primera y la segunda fila en función del desplazamiento de píxeles de la posición de desplazamiento actual.

Ciertamente es posible hacerlo, pero sería bastante trabajo (+ complejidad adicional) para algo que tan poca gente usaría. Preferiría no agregar esto personalmente.

Primero iba a solicitar la misma función. Personalmente, creo que es un paso importante hacia una mayor usabilidad. El hecho de que no tenga un soporte más amplio podría explicarse por el hecho de que es una idea relativamente nueva y que los programadores tendemos a acostumbrarnos a las limitaciones con las que tenemos que trabajar.

¿Por qué no?

@sdegutis sí, es posible, en ese entonces estaba pensando que el renderizador de lienzo estaría altamente optimizado al usar una lógica especial para invalidar solo las secciones del contenido que lo necesitaban. Desplazar el terminal ahora con el renderizador de lienzo volverá a renderizar todas las filas de todos modos, además, aunque es lo predeterminado, el plan es eliminar gradualmente el renderizador de lienzo de todos modos.

Debería ser bastante fácil hacer esto, es solo que debe hacerse para 3 renderizadores y webgl en particular necesitará algunos ajustes especiales (aumentando el tamaño del búfer de atributos ya que hay más celdas dibujadas que filas * columnas).

También me encantaría esta función, mi problema no es simplemente estético, es un problema de usabilidad. El problema es que una acción provoca demasiados saltos en la terminal y el hecho de que no haya un desplazamiento suave hace que sea casi imposible entender qué líneas se saltaron. Realmente hace que el terminal sea difícil de usar.

Cada vez que desplazo el terminal en Visual Studio Code, pierdo la noción de dónde he estado. El desplazamiento suave es una característica básica y la necesitamos.