Über zwei oder mehr vertikal geteilte Fenster scrollen

Hallo!

Ich hoffe, ich kann meine Frage einigermaßen verständlich stellen.

Monitore bekommen immer mehr Auflösung in der Breite nicht so aber in der Höhe. So gibt es z. B. Monitore im Format 21:9 mit einer gebogenen Fläche. Sicher toll für Spiele aber nicht wirklich geeignet, um langen Programmcode darzustellen – hier wären Monitore mit eine hohen vertikalen Auflösung besser, aber einen Curved-Monitor hochkantig zu drehen? 😵‍💫

Eine gute Abhilfe wäre es, ein Fenster, welches eine Datei geladen hat, vertikal so zu teilen, dass beim Scrollen der Inhalt beider Fenster bewegt wird. In anderen Worten keine zwei unabhängige Fenster (das geht heute schon) sondern dass derselbe Inhalt sich über beide geteilte Fenster erstreckt.

Angenommen, es passen vertikal 50 Zeilen auf dem Bildschirm. Nun teile ich das Fenster vertikal, wodurch ich im ersten (linken) Fenster die Zeilen 1–50 und im zweiten (rechten) die Zeilen 51–100 darstellen kann. Wenn ich den Cursor nach unten bewege, soll dieser am unteren Rand (Zeile 50) auf die Zeile 51 (Erste Zeile des zweiten Fensters) gehen, wenn ich noch einmal auf Pfeil nach unten drücke. Dann scrollt dieser bis zur Zeile 100. Scrolle ich dann weiter, so scrollen beide Fenster wie in einem Schlauch. Damit könnte ich in diesem fiktiven Beispiel 100 Zeilen gleichzeitig darstellen und darin arbeiten.

Was in VS geht, sind vertikale Dokumentgruppen, in denen ich dieselbe Datei an unterschiedlichen Stellen darstellen und bearbeiten kann. Aber ein fensterübergreifendes Scrollen geht nicht (siehe Bild mit drei Dokumentgruppen mit jeweils derselben Datei):

Nun meine Frage: Gibt es eine Möglichkeit, dieses Vorhaben zu realisieren? Eventuell mit Hilfe von einer Erweiterung?

Für eure Hilfe im Voraus lieben Dank!

René

In Visual Studio ist mir nichts derartiges bekannt.

In WPF könntest Du dir aber behelfen, indem Du die ScrollViewer aneinander "hängst":

scrollViewer.ScrollToVerticalOffset(previousScrollViewer.VerticalOffset + previousScrollViewer.ViewportHeight);

Visual Studio ist meines Wissens auch WPF, also kannst Du vielleicht sowas nach bauen.

Monitore bekommen immer mehr Auflösung in der Breite nicht so aber in der Höhe. So gibt es z. B. Monitore im Format 21:9 mit einer gebogenen Fläche. Sicher toll für Spiele aber nicht wirklich geeignet, um langen Programmcode darzustellen

Früher waren die Monitore kleiner als heute - was hat sich geändert, dass Du jetzt mit den größeren Monitoren nicht mehr auskommst?
Bei mir kommt es nur selten vor, dass die Methode überhaupt in die Nähe der Höhe des Monitors kommt.
Und auch Klassen sollten nicht so komplex sein, dass man mehrere Methoden gleichzeitig überblicken muss, um effektiv arbeiten zu können.
Im Gegenteil: Meine erste Amtshandlung in einer Klasse ist immer "Outlining => Collapse to Definitions" und in den meisten Fällen reicht das aus, um einen Überblick zu gewinnen.

PS:
Ich habe 32 Zoll, WQHD und immer auf 85% Zoom.

Mein Kollege meinte auch, ich bräuchte keinen so langen Schlauch, denn so große bzw. Lange Methoden wären sowieso ein Zeichen gegen das gute Software-Engineering. Mag in vielen Fällen stimmen, nicht aber in allen. Darüber hinaus wäre es schön, wenn man über eine Klasse, die mehr als 50 Zeilen hat (was durchaus vorkommen kann), über mehr als 100 Zeilen scrollen könnte. Ich würde gerne die Wahl haben, wenn solche breite Monitore sowieso zum Standard geworden sind.

Klar kann ich einen flachen 40-Zoll-Moni hochkant betreiben – dann hätte ich auch einen langen Scrollbereich, bekäme es aber mit den Nackenmuskeln zu tun 🤕

Ich würde gerne die Wahl haben, wenn solche breite Monitore sowieso zum Standard geworden sind.

Sind sie aber nicht und werden sie wahrscheinlich auch nie werden. Der Standard wird 16:9 bzw. 16:10 noch sehr viele Jahre, wenn nicht gar immer bleiben.
In vielen Unternehmen hast Du sogar noch 4:3 Monitore - kein Scherz.

Wide Screen haben gewisse Use Cases - aber sicher nicht "große Methoden in der Software Entwicklung". Da hat der Kollege schon den richtigen Hint für 99% der Fälle gegeben. Und für 1% der Fälle bei einer Randerscheinung so ein Feature...? Well...
Ganz nett is aber der Use Case, dass man in VS so zwei verschiedene Dateien nebeinander offen haben kann

In vielen Unternehmen hast Du sogar noch 4:3 Monitore - kein Scherz.

Kann ich bestätigen.
Letztes Jahr erst, die halbe Firma hatte steinalte Monitore von 2006 oder früher, genau habe ich es nicht herausgefunden.
Ein Monitor alleine war schwerer als der gesamte PC 😁

Abgesehen davon:
Wenn Du in der Höhe mehr Platz haben willst, dann stell doch einen 19:9-Monitor hochkant auf?
Ein ehemaliger Kollege hatte das mit zwei von drei Monitoren gemacht und darauf geschworen.
Mein Fall war's nicht, dafür nutze ich zu gerne den horizontalen Platz für zusätzliche Tools.

Und wenn es nur um den Überblick in der Klasse geht, tut's ja auch ein zweites Fenster oder - was ich persönlich auch sehr mag - die Map-Mode ScrollBar.
Für alles, was zu groß ist, gehe ich immer erst mal durch die Methoden und klappt auf, was für mich relevant ist (sieht man dann auch in der ScrollBar). Bei Refactoring gehe ich auch gerne hin und splitte erst mal die Methoden auf

Danke für eure Kommentare.

Sicher wäre so eine Hilfe nicht für jeden richtig. Es gibt auch viele anderen Eigenschaften von VS, die man wenig oder gar nie braucht – das liegt i. d. R. daran, dass nicht jeder dieselben Anforderungen hat. Das ist auch gut so: Jeder soll sich seine Umgebung so zusammenstellen, wie sie für ihn im Rahmen seiner Möglichkeiten am sinnvollsten ist.

Ich habe auf visualstudio.com den Wunsch geäußert und hoffe, dass er irgendwann in die Tat umgesetzt wird:

https://developercommunity.visualstudio.com/t/split-panels-scroll-synchronously/1665652

LG

René

VS ist historisch gewachsen.
Nur weil Funktionen heute vielleicht nicht mehr viele nutzen, mag das in der Vergangenheit anders gewesen sein.
Auch gibt es viele Funktionen, dessen Nutzerkreis Du auch einfach nicht kennst: Microsoft arbeitet sehr viel mit großen Unternehmen zusammen, die 1000+ Lizenzen besitzen.
Da kann es aufgrund des Umsatzes sein, dass Features rein kommen, die nie für wen anders passen werden.

Es hindert dich aber ja nichts einfach eine Extension zu schreiben.
Dann siehst auch, ob Du alleine mit der Anforderung bist oder es noch mehr mit diesem Bedarf gibt.

Auch gibt es viele Funktionen, dessen Nutzerkreis Du auch einfach nicht kennst: Microsoft arbeitet sehr viel mit großen Unternehmen zusammen, die 1000+ Lizenzen besitzen.

Hast Du Beispiele dazu? Also zu den Funktionen.

Theoretisch ja, aber ich weiß nicht ob ich das sagen darf, weil da mein Wissen aus NDA-Terminen stammt.
Dass aber Microsoft hier mit großen Kunden zusammenarbeitet, das is nichts neues. Das wird ja auch immer wieder in Visual Studio-Videos genannt.

Mir geht's nicht um die Firmen oder Projekte, nur um die Visual Studio Features, die wollte ich mir anschauen 🙂

Joa, weiß trotzdem nicht, ob ich das sagen darf 🙂
Daher lieber safe than sorry.

Einige Dinge sind ja Open Source, da kannst einfach in GitHub gehen und Feature Request anschauen: https://github.com/dotnet/razor-tooling/labels/feature%20request
Da gibts dann oft auch die Note Customer Asked, zB https://github.com/dotnet/razor-tooling/issues/4297

Aber letzten Endes ist die Herkunft ja egal.
Man muss nur verstehen, wie es funktioniert, dann versteht man auch, dass es eben Features gibt, die man selbst einfach nicht braucht.
Ist ja bei euren Kunden nicht anders: Bezahlkunden werden natürlich anders priorisiert, auch wenn man das von Außen nicht sieht.

Für Visual Studio Code gibts sowas bereits: https://marketplace.visualstudio.com/items?itemName=dqisme.sync-scroll
Da kannst du einen Offset angeben, damit sollte das möglich sein.
Für VS musst du dir dann vielleicht selber was bauen, sollte ja noch im Rahmen des Möglichen sein.