Terminal: [Conpty] Unterstützung für Mauseingabe hinzufügen

Erstellt am 18. Feb. 2019  ·  48Kommentare  ·  Quelle: microsoft/terminal

Am: Microsoft Windows [Version 10.0.17763.134]

Ich habe conpty in meinem Terminalemulator implementiert:
https://github.com/wez/wezterm

Ich kann target\debug\wezterm.exe erfolgreich ausführen, um Konsolenanwendungen wie cmd.exe powershell.exe und bash .

Das Problem, das ich sehe, ist, dass, wenn ich bash starte, entweder indirekt über cmd.exe oder direkt über den bash-Launcher, conpty die Maus zu verschlucken scheint, die Escape-Sequenzen meldet; Ich sehe nicht, dass sie von meinem Terminal-Parser empfangen werden, und daher hat vim trotz der Konfiguration mit set mouse=a keine effektive Mausunterstützung.

Das Ausführen derselben WSL-Installation über wsl-terminal hat funktionierende Mausunterstützung, und wezterm ist seit etwa einem Jahr mein täglicher Treiber unter Linux mit funktionierender Mausunterstützung, sodass wir eine offensichtliche Fehlkonfiguration mit ausschließen können vim und der Parser in wezterm .

Ich habe auch versucht, echo -e "\e[?1000h" manuell von der Shell aus zu aktivieren. normalerweise (unter linux und über wsl-terminal) führt dies dazu, dass Klicks im Terminal Daten an die Shell senden (die als Mülleingabe erscheinen), aber wenn ich mein Terminal mit conpty ausführe, werden diese auch irgendwo verschluckt.

Gibt es etwas Besonderes, damit die Apps, die ich in meinem pty spawne, mit der Maus arbeiten können?

Falls Sie den Schlüsselteil des Codes noch einmal überprüfen möchten, lautet die relevante Datei:
https://github.com/wez/wezterm/blob/master/src/winpty.rs
Der Flow besteht darin, CreatePipe ein Paar Pipes, CreatePseudoConsole , zu übergeben und diese dann über die threadproc-Attribute an ein erzeugtes untergeordnetes Element zu übergeben, wie dies auch in den Beispielen in den MSDN-Dokumenten und in diesem Repository der Fall ist.

Area-Interop Issue-Feature Product-Conpty

Hilfreichster Kommentar

Nur ein FYI an alle Community-Mitglieder, die sich das vielleicht angeschaut haben (/cc @SamuelEnglard!) Wir haben offiziell die Arbeit des Entwicklerteams dafür gebucht. Ich hoffe, wir treten Ihnen nicht auf die Zehen!

Alle 48 Kommentare

Hey @wez ,
Leider überträgt ConPTY keine Mausberichte (oder, von einer gehosteten Anwendung, _Anfragen für Mausberichte_). Wir haben ein Backlog-Element, das dies verfolgt, und hoffen, dass wir es bald erreichen werden.

Leider können wir nicht einfach codierte Mausereignisse durchgeben: Da ConPTY Standard-Windows-Konsolenanwendungen hosten kann, die erwarten würden, dass MOUSE_EVENT s über ReadConsoleInput eingehen, werden wir muss etwas übersetzen.

Ansonsten klingt es so, als ob Sie die Pseudokonsole richtig einrichten.


Verfolgung: MSFT: 20469462

@DHowett-MSFT danke für die Antwort!
Es ist ein bisschen schade, dass die Maus-Berichterstattung noch nicht da ist, aber trotzdem gut, dass der Rest der Pty-Sachen jetzt möglich ist!

Ich habe nichts hinzuzufügen, außer dass ich wirklich Mausunterstützung mit ConPTY möchte. Da alacritty jetzt ConPTY-Unterstützung bietet, ist alacritty + ssh + tmux ein unglaubliches Linux-Terminal unter Windows, nur die Mausunterstützung fehlt jetzt.

Ich bin ein starker Benutzer von Mitternachtskommandant in meiner Ubuntu-Bash-Shell, wo es großartig funktioniert. Leider scheint die Ubuntu-Shell-Registerkarte in Windows Terminal 0.3.2171.0 KEINE Mausereignisse an die mc-Anwendung zu senden, was die Verwendung für mich extrem schwierig macht. Ich wollte einen Fehler posten, aber ich würde dies duplizieren.

Für meine Verwendung ist das Senden von Mausereignissen von größter Bedeutung für eine gute Erfahrung mit vim und tmux.

Ich lasse hier einfach meine Unterstützung dafür fallen, plus ein bisschen Kontext. Im letzten Monat habe ich das Dual-Booten gestoppt und angefangen, den "schnellen" Ring von Windows 10 Insider Builds als meinen primären persönlichen Computer zu verwenden. Auf diesem funktioniert wsl2 perfekt, x410 funktioniert perfekt, Microsoft Terminal funktioniert großartig, Visual Studio Code wsl2 Interop funktioniert perfekt und das explorer.exe Interop funktioniert perfekt.

Dieses Mauseingabeticket ist so ziemlich das einzige, was mich davon abhält, wsl2/microsoft terminal als vernünftigen Ersatz für eine separate Partition/Entwicklungsbox zu bezeichnen. Da einige Stellen hier Open Source sind, gibt es Hinweise, wie man die Eingaben der Mausgeräte von irgendwo in /dev oder sollte ich einfach festhalten?

Danke trotzdem für all das! gefällt mir sonst sehr gut :)

Eine weitere Stimme, um zu sagen / zu bitten, dass die Mausunterstützung so süß wäre und von jedem, der tmux verwendet, schmerzlich vermisst wird, obwohl er irgendwie ohne auskommen kann.

Bitte aktivieren Sie bitte bitte die Mausunterstützung 😄

@DHowett-MSFT, Entschuldigung für die Nörgelei, gibt es einen Plan, dies in Kürze zu beheben? Sie sehen Labels/Prioritäten, die anderen Problemen zugewiesen sind, aber dies gehört nicht dazu, also einfach überprüfen. Dankeschön.

@damnskippy Priorität wird den Dingen zugewiesen, die wir im Windows-Konsolenhost im

Wenn wir es einfach wie einen Fehler "fixen" könnten, würde ich das lieben - aber es braucht viel mehr als nur eine Korrektur.

Danke für das Update. Ihre Arbeit wird geschätzt.

Ich liebe, was Sie hier tun, ich tue es, aber bis wir Mausunterstützung bekommen, müssen wir dieses Terminal mit einem anderen Terminal ergänzen, was den Zweck dieses Terminals etwas zunichte macht.

Ohne Midnight Commander ist das ein Albtraum.

Die Mauseingabe könnte im Allgemeinen nützlich sein, z. B. wenn jemand aus der Community ein DosBox-Add-In und -Profil erstellt, das in Windows Terminal ausgeführt werden kann.

Ich bin ein starker Vim-Benutzer; sogar ich vermisse die Mausunterstützung 😢

Ich habe gerade das @cinnamon-msft-Blog-Update gelesen, scheint das Team bis Ende dieses Jahres 1.0 anzustreben? Bedeutet das, dass wir bis Ende des Jahres Mausunterstützung erhalten? Wenn ja, wird gerade aktiv daran gearbeitet?

Bedeutet das, dass wir bis Ende des Jahres Mausunterstützung erhalten?

Vielleicht, aber keine harten Commits. Es ist genauso schwer abzuschätzen, wie lange Software benötigt, um P==NP zu beweisen. Ich würde sogar so weit gehen zu sagen, dass das Terminal ohne dies nicht 1.0-ready wäre.

Wenn ja, wird gerade aktiv daran gearbeitet?

Derzeit nicht. Niemand wird der Aufgabe zugewiesen, und wenn jemand im Team eine Aufgabe abbeißt, wird sie sich normalerweise selbst zuweisen.

Aus Neugier, ist hier alles nötig, um dies zu tun? Könnte ein ehrgeiziger (sprich: verrückter) Entwickler es auf sich nehmen und eine PR machen?

Sicher, jemand, der absolut ehrgeizig ist, könnte dies selbst versuchen. Wo soll ich anfangen?

Lassen Sie uns zunächst einige Bereiche skizzieren. Die Mauseingabe ist mit viel Arbeit verbunden, daher ist es am besten, klein anzufangen und an einzelnen Stücken zu arbeiten, um zu einer vollständigen Lösung zu gelangen. Ich denke, das erste, was wir an die Arbeit machen sollten, sind einfache SGR-codierte Maus-Auf/Ab-Sequenzen. Wir können an Mausrad-Ereignissen arbeiten und dann vielleicht mit der Maus darüber fahren, aber ich denke, das Klicken wird die _die meisten_ Anwendungsfälle lösen.

Schauen Sie sich zunächst InputStateMachineEngine.cpp an . InputStateMachineEngine ist für das Parsen der über conpty gesendeten Eingaben und das Übersetzen in INPUT_RECORD s verantwortlich. Ein unternehmungslustiger junger Entwickler möchte diese Klasse modifizieren, um auch diese Maussequenzen zu parsen und in INPUT_RECORD s zu übersetzen. Sobald Sie die INPUT_RECORD s haben, rufen Sie InteractDispatch::WriteInput . Dadurch werden diese INPUT_RECORD s zum Eingabepuffer hinzugefügt. Sobald sie sich im Eingabepuffer befinden, werden sie normal an die angehängte Konsolen-Clientanwendung übermittelt.

Dinge, auf die ich achten würde:

  • conhost fügt MouseEvents möglicherweise überhaupt nicht in den Puffer ein, es sei denn, wir befinden uns im Mauseingabemodus. Wenn dies der Fall ist, sollten wir diese Sequenzen ebenfalls ignorieren.
  • Apps, die eine Mauseingabe von VT wünschen, erhalten keinen Stream von INPUT_RECORD s, sondern einen Stream von Zeichen. Irgendwann in conhost versuchen wir, diese Maus INPUT_RECORD s in einen Zeichenstrom zu übersetzen, wenn sich die angehängte Anwendung im VT-Mausmodus befindet. Wenn wir diese Übersetzung durchführen, _bevor_ die Mausereignisse im Puffer sind, dann funktioniert die obige Ausführung möglicherweise nicht für VT-Anwendungen (lesen Sie: wsl ). Wenn dies der Fall ist, müssen wir sicherstellen, dass die Übersetzung von Maus- INPUT_RECORD in VT-codierte Mausereignisse für die von InputStateMachineEngine generierten Mausereignisse manuell erfolgt.

    • Wenn man es genauer betrachtet, sieht das so aus. Wir übersetzen leider nur Mauseingaben für Ereignisse, die vom Fenster ausgelöst wurden. Siehe diesen Code:

      https://github.com/microsoft/terminal/blob/2c8b3243dca0c48dd05ecd7b420a7a03b3e19c93/src/interactivity/win32/windowio.cpp#L113 -L129

      terminalMouseInput.HandleMouse synthetisiert VT-Sequenzen für die Client-Anwendung, wird aber leider nur aus dem Fenster-Proc aufgerufen. Wir müssen also irgendwie eine Möglichkeit für InputStateMachineEngine bereitstellen, dies aufzurufen (über eine neue Methode auf InteractDispatch ), und wenn diese Methode fehlschlägt, dann generieren Sie die entsprechenden INPUT_RECORD s.

    • Technisch gesehen könnte jemand den terminalMouseInput.HandleMouse Aufruf stattdessen zum Lesen des InputBuffer verschieben und versuchen, INPUT_RECORD s direkt beim Lesen zu übersetzen, aber das könnte komplizierter sein.

Was ist mit diesem Problem? Die Maus funktioniert perfekt in der alten Windows-Konsole. Bedeutet das, dass ich bei der Konsole bleiben muss, bis das Problem behoben ist?

Wenn Sie VT-Mausunterstützung benötigen, ja.

Nur ein FYI an alle Community-Mitglieder, die sich das vielleicht angeschaut haben (/cc @SamuelEnglard!) Wir haben offiziell die Arbeit des Entwicklerteams dafür gebucht. Ich hoffe, wir treten Ihnen nicht auf die Zehen!

Ich habe darüber nachgedacht, konnte aber meine eigene Zeit nicht so perfekt buchen, lol!

Ich habe gerade mit VSCode mit den Remote-Entwicklungserweiterungen gespielt und festgestellt, dass das darin integrierte Terminal tatsächlich den Mausmodus in tmux unterstützt! Panelauswahl, Fensterauswahl, Panelgrößenänderung und Scrollrad unterstützen alle Arbeiten. Ich bin jedoch neu in diesen Projekten, daher weiß ich nicht, ob das Terminal Teil des Open-Source-VS Codium ist und als Ausgangspunkt verwendet werden kann ... Entschuldigung, wenn dies keine wirklich nützlichen Informationen sind

Nur ein FYI an alle Community-Mitglieder, die sich das vielleicht angeschaut haben (/cc @SamuelEnglard!) Wir haben offiziell die Arbeit des Entwicklerteams dafür gebucht. Ich hoffe, wir treten Ihnen nicht auf die Zehen!

@DHowett-MSFT @zadjii-msft @bitcrazed Ihre Kommunikation zu diesem Thema hier und anderswo war fantastisch; Dies ist ein Beispiel für die erfolgreiche Einbeziehung der Community in die Entwicklung Ihrer Software und es zeigt sich. Ihr(e) Team(s) (Konsole/WSL/msft-linux) sind persönlich dafür verantwortlich, dass mein Unternehmen überhaupt Windows (nicht-nix) installiert. Macht weiter so mit der hervorragenden Arbeit 🥇

@thinkjrs Vielen Dank für deine

Und unseren aufrichtigsten Dank an Sie und alle in unserer Community, die für Terminal, Cascadia Code, WSL usw und Designmerkmale.

Wir haben keinen Spaß gemacht, als wir sagten, dass wir diese Funktionen für und mit unserer Community entwickeln 😜

Was ist der Prozess? Gibt es funktionelle Mäuse in WSL? Dh tmux Panelwechsel, klicken um Kanal/Server in weechat & irssi zu ändern, (n)vim Klicks, aptitude Klicks, htop klicken usw.

Was ist der Prozess? Gibt es funktionelle Mäuse in WSL? Dh tmux Panelwechsel, klicken um Kanal/Server in weechat & irssi zu ändern, (n)vim Klicks, aptitude Klicks, htop klicken usw.

@dmxt Derzeit verwende ich wsltty, das für mich die kompatibelste aller Terminaloptionen war. Ich freue mich darauf, zu Terminal zu wechseln, sobald einige dieser Funktionen verfügbar sind.

Was ist der Prozess? Gibt es funktionelle Mäuse in WSL? Dh tmux Panelwechsel, klicken um Kanal/Server in weechat & irssi zu ändern, (n)vim Klicks, aptitude Klicks, htop klicken usw.

@dmxt Derzeit verwende ich wsltty, das für mich die kompatibelste aller Terminaloptionen war. Ich freue mich darauf, zu Terminal zu wechseln, sobald einige dieser Funktionen verfügbar sind.

Ich stimme Ihrem Kommentar zu, nachdem ich in den letzten Jahren alle öffentlich bekannten Terminalemulatoren für Windows ausprobiert habe, denn zum Zeitpunkt des Schreibens ist wsltty das Beste auf dem Markt. Ihr offizielles Repo ist auch großartig, sie haben eine wunderbare Anleitung für mich, um schnell anzufangen. Mit witzig kann man sich nichts Besseres wünschen, es hat volle Mausunterstützung ohne Schluckauf in verschiedenen Workflows und Tools.

Ich habe die leichte Latenz bei I/O bemerkt und denke, dass dies der Flaschenhals des WSL1-Systems ist. Ich verwende Bare-Metal-Linux und es gibt 0 ms Latenz bei Mauseingaben.

@dmxt @offero Ich hatte Erfolg mit XShell (echte Befehlszeile von experimentellen Funktionen oder ssh in WSL) - hat Mausunterstützung usw., nur zur Info. Auch Apps, die dringend Mausunterstützung benötigen, sind Mitternachtskommandant und Mikroeditor

Bitte sehen Sie sich an, wie es in ConEmu . gelöst wird

Gibt es eine Roadmap oder einen Zeitplan, wann genau dies hoffentlich umgesetzt wird? Scheint ein ziemlich wichtiges Feature zu sein, das veröffentlicht werden muss. Es überrascht mich irgendwie, dass v1.0 veröffentlicht wird, ohne dass dies behoben wird. Ich denke, Versionierung bedeutet heutzutage nichts mehr.

@kvnxiao in der neuesten Microsoft Store-Version von Windows Terminal wird die beurteilen kann

@fat0troll Soweit ich das set mouse=a funktioniert die Mauseingabe auf alten conhost, aber nicht auf Windows Terminal 1.0.1401.0.

set nocompatible
syntax on
set number
set mouse=a
set backspace=indent,eol,start

Mit dieser vim-Konfiguration kann ich in das Fenster von vim klicken und der Cursor bewegt sich an die Stelle, an der ich geklickt habe. 1.0.1401.0, Windows Build 18368.836 (falls dies Auswirkungen darauf hat).

@kvnxiao Ich gehe davon aus, dass Sie OpenSSH_For_Windows_7.7 verwenden. Es gibt einen Fehler (in 8.x behoben), der verhindert, dass es im Mausmodus funktioniert.

Wir haben dies explizit für alle VT-Anwendungen implementiert, die Mauseingaben erhalten möchten.

Ich denke, Versionierung bedeutet heutzutage nichts mehr.

Es ist nicht nötig, unfreundlich zu sein.

In Bezug auf vim habe ich es mit neovim versucht, das für Windows als ausführbare Windows-Datei erstellt wurde. Wenn andere sagen, dass die Mausunterstützung für vim funktioniert (z. B. durch ssh / wsl usw.), dann zweifle ich nicht an Ihnen, aber dies zeigt, dass es noch keine "volle" Unterstützung gibt, was eine spezifischere Frage darstellt Frage:

Was bliebe in der Roadmap für eine "volle" Mausunterstützung im Vergleich zu dem, was Conhost derzeit kann?

Ich spreche in Bezug auf den Wunsch, generische Terminal-basierte Anwendungen zu starten, die Mauseingaben unterstützen (und in Conhost funktionieren) über WT. Zum Beispiel das Ausführen mehrerer textbasierter/Terminal-Benutzeroberflächenanwendungen, die direkt als ausführbare Windows-Datei erstellt wurden. Diese funktionieren gut, wenn sie zum Ausführen doppelt angeklickt werden, was auf die Verwendung von conhost zurückgreift, aber wenn sie über das Windows-Terminal ausgeführt werden, enden sie damit, dass nur die Maus den angezeigten Text auswählt.

@niklaskorz Was bringt es, die oben genannten Kommentare positiv und negativ zu bewerten, wenn Leute wie ich relevante Fragen zu diesem Thema haben, die möglicherweise noch ungelöst sind oder nicht?

Du hast völlig recht. Dieses Workitem, das Sie korrekterweise für Win32-Konsolenanwendungen bestimmt haben, die Mausereignisse von einem beliebigen Terminal empfangen, ist für "Terminal 1.x" (Meilenstein) vorgesehen, was darauf hindeutet, dass wir es zwischen jetzt und 2.0 angehen wollen. Eine genauere Schätzung habe ich nicht.

Danke für die Klarstellung! Etwas traurig, dass dieses Workitem nicht für 1.0 bestritten werden konnte, aber ich warte gespannt darauf, wann es soweit ist und hoffentlich nicht allzu lange warten wird 😀.

FIWW, falls Sie es nicht wussten, die neue Powershell Out-ConsoleGridView (https://github.com/PowerShell/GraphicalTools) ist dafür ein Killer-Testfall. Siehe Maus-bedingter Tracking-Bug dort: https://github.com/PowerShell/GraphicalTools/issues/95

Es basiert auf Terminal.Gui (https://github.com/tig/gui.cs).

Darüber hinaus haben wir gerade eine neue Beispiel-App für Terminal.Gui , mit der Sie die Mausunterstützung testen können, während sie im WT zum Leben erweckt wird.

Freuen uns wirklich darauf!

Kann ich irgendwie helfen, dieses Problem zu beheben? Es ist ein echter Mist für GUI-Konsolen-Apps, die mit Terminal.Gui (https://github.com/tig/gui.cs) erstellt wurden.

@kvnxiao Ich gehe davon aus, dass Sie OpenSSH_For_Windows_7.7 verwenden. Es gibt einen Fehler (in 8.x behoben), der verhindert, dass es im Mausmodus funktioniert.

Wir haben dies explizit für alle VT-Anwendungen implementiert, die Mauseingaben erhalten möchten.

Ich denke, Versionierung bedeutet heutzutage nichts mehr.

Es ist nicht nötig, unfreundlich zu sein.

Wie kann ich das eingebaute Openssh auf die neueste Version aktualisieren?

@kvnxiao Ich gehe davon aus, dass Sie OpenSSH_For_Windows_7.7 verwenden. Es gibt einen Fehler (in 8.x behoben), der verhindert, dass es im Mausmodus funktioniert.
Wir haben dies explizit für alle VT-Anwendungen implementiert, die Mauseingaben erhalten möchten.

Ich denke, Versionierung bedeutet heutzutage nichts mehr.

Es ist nicht nötig, unfreundlich zu sein.

Wie kann ich das eingebaute Openssh auf die neueste Version aktualisieren?

Ich nehme an, Sie suchen nach etwas, das in diesem Blogbeitrag beschrieben wird (Openssh-Installation von Chocolatey): https://blog.frankfu.com.au/2019/03/21/moving-from-windows-1809s-openssh-to- openssh-portable/

Ich gehe davon aus, dass Sie OpenSSH_For_Windows_7.7 verwenden. Es gibt einen Fehler (in 8.x behoben), der verhindert, dass es im Mausmodus funktioniert.

Wir haben dies explizit für alle VT-Anwendungen implementiert, die Mauseingaben erhalten möchten.

@DHowett aus diesem Kontext klingt es so, als würde die Verwendung von OpenSSH_for_Windows_8.0p1, LibreSSL 2.6.5 voraussichtlich funktionieren?

Ich verwende den Terminal-Vorschau-Build für SSH auf einen Ubuntu-Computer mit aktiviertem tmux-Mausmodus, aber meine Mauseingaben scheinen immer noch nur das Terminal selbst zu steuern.

Ich habe auch versucht, den Server auf OpenSSH 8.0 zu aktualisieren, aber auch das hat nicht geholfen.

Verhindert dieses Problem immer noch, dass so etwas funktioniert?

Ah, die x in 8.x könnten 1 sein. Mir war nicht bewusst, dass sie einen 8.0-Build veröffentlicht haben.

Ah, das x in 8.x könnte 1 sein. Mir war nicht bewusst, dass sie einen 8.0-Build veröffentlicht haben.

Ich werde das mal versuchen.

Es klappt! Erstaunlich, danke!

Ich begann dieses Problem zu verstehen.

Leider implementiert MS noch keine Mauseingabefunktion der Win32-API auf dem Windows-Terminal.
(Nur die VT-Escape-Sequenz wird unterstützt.)

Ich habe versucht, ReadConsoleInputW und PeekConsoleInputW in meiner Anwendung zu ersetzen
um mit der Maus auf dem Windows-Terminal zu arbeiten.

Zuerst führe ich den folgenden Code aus.

SetConsoleMode(hin,  ENABLE_VIRTUAL_TERMINAL_INPUT);
SetConsoleMode(hout, ENABLE_PROCESSED_OUTPUT | ENABLE_VIRTUAL_TERMINAL_PROCESSING);
char *vt_mouse_input_enable_cmd  = "\x1b[?1000h\x1b[?1003h\x1b[?1006h";
DWORD written;
WriteConsoleA(hout, vt_mouse_input_enable_cmd, strlen(vt_mouse_input_enable_cmd), &written, NULL);

Dann kann die Mauseingabe als VT-Escape-Sequenz (sgr-1006) empfangen werden (zB \x1b[<0;10;20M ).

Aber es trat ein anderes Problem auf.

Einige Tasteneingaben (wie Pfeiltasten) werden auch als VT-Escape-Sequenz empfangen (zB \x1b[A ).

Ich habe versucht, diese unerwünschte VT-Escape-Sequenz in ein Schlüsselereignis der Win32-API umzuwandeln.
aber das ist unvollständig.
(virtueller Schlüsselcode und virtueller Scancode werden beiläufig Null usw.)

Mein Code ist hier.
https://gist.github.com/Hamayama/6add968870269f2426716fad79724b31
( PDC_read_console_input_w und PDC_peek_console_input_w sind alternative Funktionen. )

Ich möchte eine Methode zum Deaktivieren der VT-Escape-Sequenz mit Ausnahme der Mauseingabe.

zum Beispiel

char *vt_key_input_disable_cmd = "\x1b[?9XXXl";
DWORD written;
WriteConsoleA(hout, vt_key_input_disable_cmd, strlen(vt_key_input_disable_cmd), &written, NULL);

oder

SetConsoleMode(hin, ENABLE_VIRTUAL_TERMINAL_MOUSE_INPUT_ONLY);

Aber das könnte eine falsche Idee für die Zukunft sein ...

Ich habe festgestellt, dass es in src/terminal/parser/InputStateMachineEngine.cpp: 391 (Übersetzung von SGR VT-Sequenzen in INPUT_RECORD s) kein Tracking der Mausbewegung gibt.

Mit anderen Worten, das Terminal sendet VT-Sequenzen für ConPTY, aber ConPTY überwacht nur den Zustand der Maustasten. Änderungen der Mauskoordinaten werden ignoriert:

src/terminal/parser/InputStateMachineEngine.cpp: 391 :

success = _UpdateSGRMouseButtonState(id, firstParameter, buttonState, eventFlags);
success = success && _WriteMouseEvent(parameters.at(1), parameters.at(2), buttonState, modifierState, eventFlags);

Mit dem aktuellen Unterstützungsstatus für die Mauseingabe ist die folgende Option möglich.

Sie können Koordinatenverfolgung hinzufügen und die Mausbewegung beginnt in klassischen Konsolenanwendungen zu funktionieren.

src/terminal/parser/InputStateMachineEngine.hpp: 172 :

+ size_t _mouseColumn = 0;
+ size_t _mouseLine = 0;

src/terminal/parser/InputStateMachineEngine.cpp: 391 :

- success = success && _WriteMouseEvent(parameters.at(1), parameters.at(2), buttonState, modifierState, eventFlags);
+ auto mouseColumn = parameters.at(1).value_or(0);
+ auto mouseLine = parameters.at(2).value_or(0);
+ auto isMoved = mouseColumn! = _mouseColumn || mouseLine! = _mouseLine;
+ if (isMoved)
+ {
+     _mouseColumn = mouseColumn;
+     _mouseLine = mouseLine;
+ }
+ success = (success || isMoved) && _WriteMouseEvent(mouseColumn, mouseLine, buttonState, modifierState, eventFlags);

Hinweis: Bevor Sie eine klassische Konsolenanwendung starten, müssen Sie die Mausverfolgung im SGR-Format anfordern:

Windows PowerShell

PS C:\Users> [char]0x1b + "[?1003;1004;1006h"

Eingabeaufforderung

C:\Users> echo Strg+[ [?1003;1004;1006h

Parameter
  • 1003 - ANY_EVENT_MOUSE_MODE
  • 1004 - jeder nicht unterstützte Modus (zB 1001 oder 9999 ), um die Sequenz über ConPTY an das Terminal selbst weiterzuleiten
  • 1006 - SGR_EXTENDED_MODE

Als Ergebnis sendet das Terminal Mausereignisse an ConpTY, wodurch INPUT_RECORD s für die klassische Konsolenanwendung generiert werden.

Guter Fang. Wir müssen sicherstellen, dass wir das beheben, wenn wir tatsächlich umziehen, um dieses :smile:

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen