LXQt 0.17.0 ist das erste Update in diesem Jahr für die leichtgewichtige, auf Qt basierte Desktop-Umgebung. Die neue Version führt die behutsame Weiterentwicklung von LXQt fort. LXQt entstand 2014 aus der Vereinigung von Razor-Qt und LXDE-Qt und wird von Lubuntu seit 18.10 als Standard-Desktop verwendet.
Fremde Apps besser unterstützt
Unter den Änderungen findet sich die Funktion, alle Kindprozesse beim Beenden der Sitzung ebenfalls zu beenden. Dies ermöglicht es Nicht-LXQt-Apps, ihre letzten Einstellungen am Sitzungsende zu speichern. Der LXQt-Energiemanager verfügt nun über separate Leerlaufüberwachungen für den Betrieb am Stromnetz oder per Akku. sowie über eine Option zur Deaktivierung, wenn das aktive Fenster im Vollbildmodus ist. Das LXQt-Panel hat die Fähigkeit erhalten, sich bei Überlappung durch ein Fenster automatisch auszublenden.
Dateimanager unterstützt Erstellungszeit
Der LXQt-Dateimanager PCManFM-Qt unterstützt fortan die Anzeige der Erstellungszeit von Dateien. Ein neuer Eintrag im Extras-Menü erlaubt es, den von GVFS bereitgestellten Admin-Modus zu aktivieren, etwa zum Übertragen von Dateien jenseits von Benutzerrechten, aber ohne eine Root-Instanz. Die LXQt-Entwickler weisen allerdings darauf hin, dass der Admin-Modus in GVFS 1.48.0 derzeit defekt ist, er wird automatisch aktiviert, sobald der Fehler behoben ist.
QTerminal und LXQt Archiver aufgewertet
Die Unterstützung von Symbolsätzen im SVG-Format wurde verbessert. Der Terminal-Emulator QTerminal wurde mit fünf neuen Modi für Hintergrundbilder aufgewertet. LXQt Archiver kann nun Disk-Images öffnen und extrahieren, merkt sich Fenstereinstellungen und erhielt ein scrollbare Seitenleiste. Weitere Neuerungen verrät die Ankündigung zur Veröffentlichung. LXQt 0.17.0 steht im Quellcode auf GitHub zum Download bereit. Die Distributionen werden zu gegebener Zeit ihre Archive mit der neuen Version ausstatten.
Die beiden Debian-Entwickler Lisandro Pérez Meyer und Dmitry Shachnev gaben bekannt, dass sie mit dem Erscheinen der im Dezember 2020 erwarteten neuen Version Qt 6.0 von der Betreuung des Frameworks für Debian zurücktreten. Sie werden aber weiterhin die Pflege der in Debian verfügbaren Pakete von Qt 5 übernehmen.
Wenig Zeit, schwache Hardware
Als Gründe geben beide neben zunehmend fehlender Zeit auch eine nicht ausreichend potente Hardware-Build-Infrastruktur an, die eine adäquate Betreuung der riesigen Paketbasis von Qt erschweren. Pérez Meyer betont auf Nachfrage ausdrücklich, die Code-Qualität habe nichts mit der Entscheidung zu tun – Qt sei im Gegenteil ein großartiges Projekt.
C++ vorausgesetzt
Die beiden Entwickler werden Betreuern, die die Arbeit übernehmen möchten, unter die Arme greifen und auch für eine Weile deren Uploads übernehmen, falls nötig. Neue Betreuer für das Qt-Framework sollten Erfahrung in der Paketierung bei Debian mitbringen und mit C++ und Symboldateien (PDB-Dateien) umgehen können. Da Qt 6 beim Build-Prozess von qmake auf cmake wechselt, sind Erfahrungen damit ebenfalls von Vorteil.
Plasma schlecht unterstützt
Dass beide Betreuer zuletzt nicht mehr genügend Zeit für die adäquate Betreuung von Qt aufbringen können, war bereits länger erkennbar, wenn aktuelle Updates erst verspätet in Debian Unstable erschienen. Darunter leidet auch die Aktualität des Plasma-Desktops, der in Unstable derzeit als Plasma 5.17 vorliegt, während bereits im Juni Plasma 5.19 freigegeben wurde. Im Oktober wird Plasma 5.20 folgen, die das in Debian noch nicht verfügbare Qt 5.15 voraussetzt.
Alternative
Wer in Debian einen stets aktuelles Plasma in Testing oder Unstable haben möchte, dem bleibt außer dem Selbstbau derzeit nur das inoffizielle Projekt von Debian-Entwickler Norbert Preining, das derzeit Plasma 5.19.4, KDE Frameworks 5.73 und KDE Apps 20.08 installiert. Durch den Rückzug der beiden Entwickler steht zu befürchten, dass sich die Aktualität von Qt und KDE in Debian weiter verschlechtern wird.
Gestern hat The Qt Company, die an der Börse als Qt Group notiert ist, ihre Roadmap für das Qt-Framework 2020 bekannt gegeben. Dort gibt die Tochtergesellschaft von Digia ihre Pläne einschließlich der Einführung von Qt 6 bekannt. Was dort nicht steht ist, dass sich TheQt Company in letzter Zeit zunehmend von KDE und seiner Community distanziert.
Schrittweise Distanzierung
Bereits im Januar gab The Qt Companyerste Einschränkungen des mehrfach lizenzierten Frameworks bekannt. Demnach sind ab Qt 5.15 langfristig unterstützte Versionen (LTS) und das Offline-Installationsprogramm von Qt nur noch für kommerzielle Lizenznehmer verfügbar. Zudem benötigen jetzt auch Open-Source-Anwender einen Qt-Account, um Qt-Binärpakete herunterladen zu können. Quellpakete sind weiterhin auch ohne Qt-Account zugänglich.
Generell gutes Verhältnis
In einer neuen Ankündigung wird die Distanzierung von KDE und anderen freien Gemeinschaften, die Qt einsetzen noch deutlicher. Das geht aus einem Eintrag auf der Mailingliste von KDE-Entwickler Olaf Schmidt-Wischhöfer hervor. Darin beschreibt er das Verhältnis von Qt Company, dem freien Qt-Project und der KDE Free Qt Foundation als über die Jahre durchaus fruchtbar und zum Vorteil aller Beteiligter.
Diese für alle positive Ausgangssituation sei jedoch durch die Einschränkungen vom Januar gefährdet. Auf einem persönlichen Treffen im März sei dann aber das Grundgerüst für eine weitere Zusammenarbeit gelegt worden.
Corona als Vorwand?
Dem widersprechen die neuesten Informationen, nach denen KDE e. V. und KDE Free QT Foundation informiert wurden, The Qt Company sehe sich angesichts der Corona-Krise gezwungen, kurzfristig mehr Umsatz zu generieren und deshalb künftig alle Qt-Veröffentlichungen für 12 Monate nur kommerziellen Lizenznehmern zugänglich zu machen.
Strategien für den Ernstfall
Auch wenn diese Ankündigung noch nicht festgeklopft ist, sieht sich die KDE-Community veranlasst, Strategien zu entwickeln, falls Qt Company dies durchsetzt. Einen Mittelweg scheint es hier nicht zu geben, ein Fork scheint in diesem Fall unabwendbar, die Entwicklung von KDE auf der Basis von Qt zu schützen.
KDAB bietet wichtige Unterstützung
Alle Beteiligten sind sich der Tragweite einer solchen Entscheidung angesichts der Komplexität des Qt-Frameworks bewusst. Die KDE-Gemeinschaft wird bei diesem Unterfangen von dem einflussreichen Qt-Consulting-Unternehmen KDAB unterstützt, dessen Berliner Statthalter sich dahin gehend auf der Mailingliste äußerte.
Viele Projekte betroffen
Neben KDE gibt es viele weitere Projekte, die auf dem freien Software-Repository von Qt basieren und durch diese Entscheidung, wenn sie sich manifestiert, in ihrer Entwicklung beschnitten werden. Zu nennen sind hier VLC, Spotify, VirtualBox, Kolab, Mathematica, Mumble, Skype, TeamSpeak, Google Earth, Telegram und andere.
Eine lange Geschichte
KDE und Qt verbindet eine lange Geschichte, die anfangs dazu führte, dass GNOME die Oberhand bei den Desktop-Umgebungen für sich beanspruchen konnte. Mit der Veröffentlichung von KDE 1.0 im Jahr 1998 kam nämlich Kritik an der Verwendung des damals unfreien Qt-Frameworks als der Basis von KDE auf.
Qt-Entwickler Trolltech reagierte und stellte Qt in einer speziellen, freieren Version unter der QPL-Lizenz zur Verfügung. Da hatte GNOME aber bereits einen Vorsprung und wurde im frisch gegründeten Unternehmen Red Hat zum Standard-Desktop. Jahre später wurde Qt dann der GPL unterstellt.
Von Trolltech zu Nokia zu Digia
Durch die Nutzung von Qt als Basis für KDE-Software bildeten sich schnell engere Beziehungen zur mittlerweile von Nokia übernommenen Firma Trolltech. Im Juni 1998 gründeten KDE e. V. und Trolltech gemeinsam die KDE Free Qt Foundation, um den Fortbestand von Qt als freie Software sicherzustellen. Trolltech begann zudem damit, KDE-Entwickler einzustellen. Die Qt-Entwicklungsabteilung von Nokia wurde 2012 vom finnischen Software-Unternehmen Digia übernommen, die die Qt-Entwicklung dann 2016 in die Tochtergesellschaft The Qt Company auslagerte.
Abschließend bleibt zu sagen, dass, auch wenn diese Maßnahmen im Endeffekt nicht Realität werden, ist schon durch die Ankündigung klar, dass The Qt Company das KDE-Projekt als größten Nutzer des freien Qt-Frameworks nicht wertschätzt und glaubt, auf die Qt-Community verzichten zu können. Der Schaden ist entstanden und beabsichtigt.
Mit Lector betritt ein neuer Ebook-Reader die Linux-Bühne. Er basiert auf dem Qt-Framework und ist unterhalb des für Linux, macOS und Windows verfügbaren Ebook-Managers Calibre angesiedelt. Calibre bietet eine in diesem Segment unerreichte Funktionsvielfalt bis in den professionellen Bereich, die aber nur wenige Anwender wirklich ausschöpfen. Diese Vielfalt steht dann schnell mal im Weg steht, wenn man Calibre für die Verwaltung seiner privaten Ebook-Sammlung konfigurieren möchte.
Lector gegen Goliath
Hier kommt Lector ins Spiel, dessen Funktionsumfang über das reine Lesen von elektronischen Büchern hinaus auch deren Verwaltung und Sortierung in einer Datenbank umfasst. Derzeit werden die Formate Epub, Mobi, AZW, AZW3, AZW4 und PDF unterstützt. Comic-Fans bietet das Programm die Formate CBR und CBZ. Weitere Formate sollen folgen. Die Anwendung ist in Python geschrieben, als Datenbank kommt SQLite3 zum Einsatz.
Ausreichender Funktionsumfang
Das Einlesen der Büchersammlung geht auch bei einer großen Sammlung problemlos vonstatten. Bücher werden danach mit ihrem Cover angezeigt. Die Sortierung erlaubt Anzeige nach Autor und vielem mehr. Metadaten wie Genre, Titel, Erscheinungsjahr, Autor und andere können einfach per Rechtsklick editiert werden. Zudem kann Einfluss auf den Schriftsatz, dessen Größe und Farbe genommen werden, auch stufenloser Zoom ist verfügbar. Bookmarks erlauben das Markieren von Seiten und deren Verwaltung in einer Bookmark-Leiste, ein Wörterbuch gehört ebenfalls zum Funktionsumfang von Lector.
Lector ist noch an einem frühen Punkt seiner Entwicklung, funktioniert aber bereits grundlegend. Im AUR von Arch Linux findet sich die bisher einzige Version in einer Distribution. Ansonsten muss Lector aus dem Quellcode gebaut werden. Die Abhängigkeiten und eine Bauanleitung sind auf der GitHub-Seite vermerkt. Die Pakete können je nach Distribution leicht anders heißen, sind aber einfach zu identifizieren. Ein Flatpak von Lector ist bereits in Arbeit.
Im Auge behalten
Lector macht einen vielversprechenden Eindruck und könnte eine Lücke zwischen einfachen Ebook-Readern und dem Dickschiff Calibre füllen. Noch hat die Anwendung, zumindest unter Debian mit Qt 5.9 einige Fehler und stürzt gerne mal ab. Der Entwickler hat sie mit Qt 5.10.1 gebaut, das noch nicht in vielen Distributionen verfügbar ist. Vielleicht behebt das einige Fehler. Auf jeden Fall werde ich Lector im Auge behalten und weiterhin testen.
Amarok 2.9.0 »Hibernaculum« ist die neueste Version von KDEs früherer Vorzeigeanwendung Amarok. Lange war es still um den ehemals sehr beliebten Jukebox-Player. Seit August 2013 verharrte Amarok, der freie Audioplayer für unixoide Betriebssysteme und Windows, auf Version 2.8. Eine Beta-Version Amarok 2.9 wurde im August 2015 erstellt, fand aber keinen Eingang in die Distributionen. Jetzt erst folgte die stabile Version.
Vorbereitung auf Amarok 3.0
Amarok 2.9.0 basiert immer noch auf den in einigen Distributionen bereits aus den Archiven entfernten KDELibs 4 und Qt 4 und behebt mehr als 20 Fehler. Es ist die letzte Ausgabe des Players, die auf Qt4 basiert. Im KDE-Git wird seit einiger Zeit die Portierung auf Qt 5 und KDE Frameworks 5 vorangetrieben und macht gute Fortschritte. Diese Version wird dann als Amarok 3.0 hoffentlich in neuem Glanz erstrahlen. In der Ankündigung heißt es jedenfalls, der kf5-Zweig werde »bald« der neue Master-Branch.
