kwrite mit Tabs? Wirklich??? |
Ich weiß nicht, ob das so recht in die Rubrik Bugs gehört, da es ja eigentlich kein Bug ist, wenn der Lieblings-Text-Editor so verändert wird, daß er massiv den eigenen Workflow stört. Aber da ich sonst nicht weiß wohin...dann eben hier. Worum geht es eigentlich? In Debian bookworm KDE mit der Kwrite Version 4:22.12.3-1 verwendet kwrite neuerdings genau wie Kate Tabs. Ich habe keine Ahnung was die Entwickler sich dabei gedacht haben in einen simplen Texteditor so etwas einzuführen, aber es gab einen kleinen Aufschrei in der Linux-Gemeinde. Die Logik dahinter ist ja auch nachvollziehbar, denn wer Tabs will, kann ja kate nehmen. Wer nur einen kleinen, ungeheuer hilfsbereiten Editor haben will ohne Tabs nimmt kwrite. In mehreren Foren haben sich mehrere Leute darüber beschwert, daß dieses Verhalten ihren Workflow stören würde. Und dem kann ich nur beipflichten, da es meinen Workflow auch stört und zwar massiv. Wenn ich an Programmen oder Webseiten schreibe, kommt es sehr oft vor, daß ich Code-Teile kopiere oder auch Vergleiche. Hat man zwei separat geöffnete Fenster, kann man die schön nebeneinander anordnen und den Code vergleichen und benötigte Teile kopieren. In Tabs kann man keine Fenster nebeinander anordnen, was einen optischen Vergleich durch lesen sehr schwierig macht. Jetzt kann man die Sache von der Seite der Entwickler betrachten und der Anwender. Die Entwickler hatten es sicher nur gut gemeint und sind jetzt vermutlich ziemlich genervt, daß soviel Kritik kommt, wo sie ja noch nicht einmal Geld dafür bekommen und ihre Freizeit opfern um so ein nützliches Programm zu schreiben. Aber liebe Entwickler, ihr müßt auch die andere Seite verstehen. Der Mensch ist ein Gewohnheitstier und ich bin jedes Mal aufs neue genervt, wenn ich meine Arbeitsweise umstellen muß und meine gewohnten Handlungen über Bord werfen kann. Und in dem Fall müßte ich meine Arbeitsweise sehr umstellen und würde mir das Leben um einiges schwerer machen. Und leider kann man dieses Verhalten auch nicht abstellen. Also eine Frage: Ist es wirklich so schwer eine große Veränderung eher als zusätzliches Feature zu implementieren, damit der User eine Wahl hat wie er Arbeiten möchte? Sehen wir uns mal an, wo das Problem bei meiner Arbeitsweise besteht: Ich arbeite mit kwrite an HTML-Dokumenten für meine Webseite und an C/C++ oder Qt-Programmen. Da kommt es sehr oft vor, daß ich mehrere Dateien auf einmal öffnen will um kleine Schnipsel umzukopieren oder auch um Programmteile zu vergleichen. Dazu öffne ich den Konqueror als Dateibrowser, markiere meine Dateien und mit einem Rechtsklick und der Auswahl "Öffnen mit kwrite" werden alle ausgewählten Dateien mit kwrite geöffnet. Bisher unter der alten kwrite Version (kwrite 4:20.12.2-1) in Debian bullseye wurde jede Datei in einem eigenem kleinen Fenster geöffnet. Mit der neuen Version (kwrite 4:22.12.3-1) unter Debian bookworm werden alle in einem Tab geöffnet. Und man kann diese Tabs auch nicht herauslösen und zu einem eigenständigen kwrite-Fenster machen. Die einzige Möglichkeit jede Datei in einem eigenem kwrite Fenster zu öffnen ist, jede Datei einzeln anzuklicken. Nur in dem Fall werden sie in separaten kwrite Instanzen geöffnet. Leider kann man dieses Verhalten nicht abstellen, obwohl es einen Knopf für die Anzahl der Tabs gibt (Standardmäßig ist die Anzahl der Tabs "Unbegrenzt"). Denn stelle ich die Anzahl der Tabs auf 1 und führe die Aktion erneut aus, sehe ich zwar keine Tabs mehr, aber es wird nur die letzte ausgewählte Datei geöffnet. Alle Anderen Dateien werden scheinbar geöffnet, sind aber nicht zu sehen, quasi unsichtbar! Das merkt man, wenn man ohne kwrite zu schließen die Anzahl der Tabs wieder erhöht. Dann tauchen auf einmal alle ausgewählten Dateien in Tabs wieder auf. Meine erste Frage die sich aufdrängte war, ist das ein Bug oder soll das so sein? Denn von der Logik her ist es totaler Blödsinn die Anzahl der Tabs zu begrenzen, wenn beim Öffnen von mehreren Dateien keine andere Anzeigemöglichkeit für die Dateien hergenommen wird und sie quasi versteckt sind. Wegen diesem Verhalten ist es aus meiner Sicht daher unmöglich mit der Konfiguration von kwrite das alte Verhalten wieder herzustellen. Wie bereits geschrieben, das Einzige, was man machen kann ist jede Datei separat anzuklicken, aber bei sehr vielen Dateien artet das in eine Klickorgie aus. Daher, bitte verzeiht mir liebe Entwickler, ist die neue Version von kwrite für mich im Moment inakzeptabel.
Aus diesen Gründen mußte eine Lösung her und mein erster Gedanke war schlicht und ergreifend, ich installier mittels dpkg -i das alte kwrite wieder von Debian bullseye. Das hat auch soweit funktioniert, nur wenn man das System mittels apt-get updaten will oder neue Pakete installieren will, verweigert apt-get die Installation oder das Update mit folgendem Hinweis:
kde-baseapps : Hängt ab von: kwrite (>= 4:22.12.3) aber 4:20.12.2-1 ist installiert E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne Angabe eines Pakets (oder geben Sie eine Lösung an). Beheben kann man das in dem man wieder die aktuelle Version installiert: # apt-get install kwrite Aber es wäre schon mühsam gewesen jedes Mal für ein Update oder eine Installation eines Programms kwrite auf die aktuelle Version upzudaten und danach wieder die alte Version drüber zu bügeln. Leider war da die sehr restriktive Debian Politik was das mischen von den unterschiedlichen Zweigen wie stable, testing und unstable (oder in dem Fall oldstable) anbelangt, nicht zum ersten Mal ein rießiger Stolperstein. Okay, ich weiß, Debian möchte das bestmöglichst stabilste System für den Anwender und das erreicht man natürlich nur, wenn alle Pakete getestet, überprüft und soweit es der Überprüfungsstatus zuläßt auch aktuell sind. Aber liebe Debian Enwickler, auch hier muß ich eine kleine Kritik loswerden: Man könnte es ja auch so machen, daß man nur eine Warnung rausschmeißt, daß Pakete von anderen Zweigen das System instabil werden lassen oder gefährden, es aber grundsätzlich erlaubt wäre und funktionieren würde. Ob das System danach instabil ist, sieht man ja und man könnte dann ja wieder die vorherigen Pakete installieren. Aber das nur so am Rande. Wegen der Mühseligkeiten von Lösung 1, habe ich mich für Lösung Nr. 2 entschieden: Mit den Quellpaketen von bullseye ein kwrite-Paket basteln, welches einfach eine neuere Versionsnummer erhält, als die von bookworm verwendete. Somit kann man das alte kwrite installieren (ohne die verhassten Tabs) und apt ist zufrieden. Und die Einzige zusätzliche Arbeit die ich hatte, war das Farbprofil anzupassen, welches für die Färbung von Programmcode da ist. Da hatte sich auch was geändert und manche Teile meiner Programmdateien sahen ungewohnt rosa aus... Wer auch das alte kwrite von bullseye wieder zurück haben will, hier ist die kompilierte Version aus den bullseye-Quellen zur Installation unter bookworm: kwrite_22.12.3-2_amd64.deb Die von bookworm verwendete Version hat 4:22.12.3-1 und meine selbstkompilierte 4:22.12.3-2. Sollte mal eine neuere kwrite Version für bookworm rauskommen bei der die Tabs immer noch nicht abschaltbar sind, werde ich es wohl neu übersetzen müssen mit noch höherer Versionsnummer... |
Zurück zur Auswahl |