Xterm.js: Défilement fluide

Créé le 11 déc. 2017  ·  16Commentaires  ·  Source: xtermjs/xterm.js

En tant que personne novice dans l'utilisation des CLI, je trouve qu'il est plus difficile d'un point de vue cognitif de visualiser le défilement ligne par ligne utilisé dans les terminaux, par opposition au défilement fluide de la plupart des autres applications. J'ai appris que c'est parce que dans un terminal, le caractère et non le pixel est la plus petite unité d'affichage.

Est-il possible (et souhaitable) que xterm.js contourne ce problème et intègre une option de défilement fluide basée sur les pixels ?

J'ai initialement demandé à @albinekb la même chose pour Hyper (https://github.com/zeit/hyper) et il m'a référé à ce projet car Hyper utilise xterm.js.

aremouse-support typenhancement

Commentaire le plus utile

quelque chose que si peu de gens utiliseraient

Tous ceux qui font défiler avec le touchpad l'utilisent en VTE, qu'ils le veuillent ou non :D

Tous les 16 commentaires

C'est certainement possible à faire mais ce serait pas mal de travail (+complexité ajoutée) pour quelque chose que si peu de gens utiliseraient. Je préférerais ne pas ajouter cela personnellement.

C'est compréhensible et juste. Merci pour votre travail !

Pour info : VTE (Terminal GNOME et amis) le fait depuis la version 0.44. (Bien sûr, cela ne fonctionne que dans le défilement de l'émulateur de terminal, pas lorsque, par exemple, le défilement du fichier dans un éditeur de texte.)

quelque chose que si peu de gens utiliseraient

Tous ceux qui font défiler avec le touchpad l'utilisent en VTE, qu'ils le veuillent ou non :D

@egmontkob J'ai le terminal gnome 3.18.3 ici et cela ne semble pas fonctionner, la section de défilement dans les paramètres de profil ne semble pas non plus avoir de paramètre?

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

gt 3.18.3 signifie très probablement que vous avez vte 0.42, alors que cette fonctionnalité est nouvelle dans 0.44.

Pas de nouveau paramètre (il y a une demande à

Quelqu'un a déjà exprimé son aversion pour le fait que cela ne soit pas configurable dans VTE. Bien sûr, c'est à vous de décider si vous implémentez cette fonctionnalité dans xtermjs, et si vous le faites, si vous la rendez configurable.

Je pense que cela pourrait être un point de données précieux pour vous que cette fonctionnalité existe dans VTE depuis plus d'un an et demi maintenant, et "forcée" sur tous les utilisateurs de VTE qui utilisent un trackpad (plutôt que la molette de la souris qui envoie des "unités" de défilement) pour laquelle nous faisons encore défiler des lignes entières), et pendant ces périodes, j'ai entendu 2 ou peut-être 3 plaintes au total pour ramener l'ancien comportement. Si cette fonctionnalité était nulle, il y aurait beaucoup plus de plaintes.


Je n'ai pas de chiffres d'utilisation ou de ratio sur VTE, le plus proche que j'ai est les résultats de ce sondage (notez que la date de l'article est mutilée, sur la base des horodatages des commentaires, il s'agit d'un vote vieux de 2 ans) ce qui suggère que VTE la part de marché parmi les émulateurs de terminaux Linux est de l'ordre de 50 %, c'est-à-dire assez importante. Donc, beaucoup de gens utilisent déjà le défilement fluide.


Je suis nouveau avec xtermjs et mes amis et je ne l'ai pas encore essayé, il suffit de voir que des choses sympas se passent ici. Je ne suis pas sûr d'avoir la bonne architecture en tête, mais si je le fais, le terminal GNOME est à VTE ce que hterm est à xtermjs. VTE est un widget GTK+ faisant de l'émulation de terminal. Il existe une douzaine d'applications d'émulation de terminal plus ou moins populaires utilisant VTE, notamment GNOME Terminal, Xfce4 Terminal, Terminator, Tilix...


Si vous souhaitez essayer le comportement, le moyen le plus simple (pour cela, ainsi que pour toutes les fonctionnalités VTE qui ne nécessitent pas la coopération du terminal GNOME) est de compiler uniquement VTE et de démarrer son application de test :

  • Obtenir de git ou tarball
  • ./autogen.sh (git) ou ./configure (tarball)
  • make
  • ./src/app/vte-2.91 (à partir de 0,51) ou ./src/testvte (jusqu'à 0,50) ou ./bindings/vala/vte-2.91 ou ./src/vte-2.91 (jusqu'à 0,50, a été déplacé vers un autre répertoire à un moment donné)

J'utilisais la molette de la souris, c'est mon problème :sweat_smile:

Dans le post initial, j'ai oublié de mentionner le détail assez important que j'utilise effectivement un trackpad. Sans tenir compte des utilisateurs du trackpad ou des utilisateurs d'autres méthodes de saisie tactiles, je comprends que peu de gens préfèrent le défilement basé sur les pixels.

OMI, il est sûr de dire que c'est juste attendu par les utilisateurs à ce stade. Je veux dire, même hterm l'a.

Ce n'est pas vraiment possible avec le moteur de rendu canvas, mais cela devrait être assez facile à réaliser avec le moteur de rendu webgl https://github.com/xtermjs/xterm.js/pull/1790 qui devrait remplacer le moteur de rendu canvas. Pour le moteur de rendu DOM, nous pouvons y parvenir en ayant des lignes partiellement visibles en haut et en bas. En tant que tel, je considère que cela est bloqué sur #1790

Autre chose à prendre en compte : le fait que ydisp ne soit pas un entier et que plus de lignes que Terminal.rows soient visibles brise certaines hypothèses formulées dans le code, par exemple, comment cela affecte-t-il la prise en charge du lecteur d'écran ?

Ce n'est pas vraiment possible avec le moteur de rendu canvas

Pourquoi pas? Cela devrait être aussi simple que de dessiner un nombre de viewportHeight + 2 de lignes et de décaler quelque part entre la première et la deuxième ligne en fonction du décalage de pixel de la position de défilement actuelle.

C'est certainement possible à faire mais ce serait pas mal de travail (+complexité ajoutée) pour quelque chose que si peu de gens utiliseraient. Je préférerais ne pas ajouter cela personnellement.

Fwiw j'allais demander la même fonctionnalité. Personnellement, je pense que c'est une étape importante vers une plus grande convivialité. Le fait qu'il ne soit pas plus largement supporté pourrait s'expliquer par le fait qu'il s'agit d'une idée relativement nouvelle et que nous, programmeurs, avons tendance à nous habituer aux limitations avec lesquelles nous devons travailler.

Pourquoi pas?

@sdegutis ouais c'est possible, à l'époque je pensais que le moteur de rendu de canevas serait hautement optimisé en utilisant une logique spéciale pour invalider uniquement les sections du contenu qui en avaient besoin. Faire défiler le terminal maintenant avec le rendu de canevas rendra de toute façon toutes les lignes, et même si c'est la valeur par défaut, le plan est de supprimer progressivement le rendu de canevas.

Cela devrait être assez facile à faire, c'est juste que cela doit être fait pour 3 moteurs de rendu et webgl en particulier aura besoin de quelques ajustements spéciaux (augmentation de la taille du tampon d'attributs car il y a plus de cellules dessinées que de lignes * cols).

J'aimerais aussi cette fonctionnalité, mon problème n'est en fait pas simplement esthétique, c'est un problème de convivialité. Le problème est qu'une action provoque beaucoup trop de sauts sur le terminal et le fait qu'il n'y ait pas de défilement fluide rend presque impossible de comprendre quelles lignes ont été sautées. Cela rend vraiment le terminal difficile à utiliser.

Chaque fois que je fais défiler le terminal dans Visual Studio Code, je perds la trace de l'endroit où je suis allé. Le défilement fluide est une fonctionnalité de base et nous en avons besoin.

Cette page vous a été utile?
0 / 5 - 0 notes