Bericht KDE Plasma 6 im Überblick: Mega-Release bringt Qt 6 und Wayland als Standard

[Evil E-Lex]

Ich wäre ja schon glücklich wenn man endlich mal Multiscreen-Wallpaper verwenden könnte und diese nicht wie von KDE Usern vorgeschlagen zerschneiden muss um sie dann einzeln den Bildschirmen zuzuweisen...

Allerdings. Ich bin heute fast von Stuhl gefallen, als ich diesen "Lösungsvorschlag" gelesen hab.

Was mir davon ab ein Dorn im Auge ist: Wenn ich per Drag-and-Drop eine Datei in ein Verzeichnis lege, erscheint bei Linksklick ein Kontextmenü. Es mag ja sein, dass das das ein KDE-Markenzeichen ist, es widerspricht aber der Bedienung von allen anderen mir bekannten Desktop-Umgebungen. Das man dieses Verhalten nicht optional auf das "übliche Verhalten" umstellen kann, wo man sonst jede Kleinigkeit einstellen kann, will mir nicht in den Kopf.

 

[rarp]

Was mir davon ab ein Dorn im Auge ist: Wenn ich per Drag-and-Drop eine Datei in ein Verzeichnis lege, erscheint bei Linksklick ein Kontextmenü. Es mag ja sein, dass das das ein KDE-Markenzeichen ist, es widerspricht aber der Bedienung von allen anderen mir bekannten Desktop-Umgebungen. Das man dieses Verhalten nicht optional auf das "übliche Verhalten" umstellen kann, wo man sonst jede Kleinigkeit einstellen kann, will mir nicht in den Kopf.

Ich finde das Popup super.
Um es zu umgehen, kannst du zum Kopieren Strg+LMB bzw. zum Verschieben Shift+LMB nutzen.

 

[Evil E-Lex]

Ich weiß, das will ich aber nicht. Es soll sich optional so verhalten wie überall sonst auch.

 

[rarp]

Dann ist Plasma wohl nix für dich.

 

[sedot]

Als Hinweis;
Überlegt ob ihr alle möglichen random Themes aus dem KDE Store unbedingt installieren müsst. Ein inzwischen entferntes hat einfach mal rm -rf auf alle durch den User gemountete Verzeichnisse ausgeführt.

https://www.reddit.com/r/openSUSE/c...ed_a_global_theme_it_erased_all_my/?rdt=32774

Außerdem, Backups. Macht Backups wenn euch euer digitales Gut wichtig ist.

 

[Kuristina]

Wow. Ich weiß nicht genau, wie Themes bei KDE aufgebaut sind, aber das sind wohl plugins, schreibt da der eine. Da bin ich ja froh, bei mir nur gtk (.css) zu haben. ^^

 

[sedot]

Da bin ich ja froh, bei mir nur gtk (.css) zu haben.

Yup, geht mir auch so – ich unterstelle mal, der Author hatte keine böse Absicht. Hoffentlich ändert sich grundsätzlich irgendwas beim KDE Themes Store.

 

[andy_m4]

Ein inzwischen entferntes hat einfach mal rm -rf auf alle durch den User gemountete Verzeichnisse ausgeführt.

Ich finde ja ohnehin spannend, das Themes Shellbefehle absetzen können bzw. überhaupt Zugriff aufs Dateisystem haben. Ich hätte mal vermutet, das das mehr oder weniger nur Style-Sheets plus ein paar Grafiken sind. Meinetwegen noch eingeschränktes Skripting. Aber wenn das was Du beschreibst möglich ist, dann ist dann würde ich das als Sicherheitslücke deklarieren.

ich unterstelle mal, der Author hatte keine böse Absicht.

Fehler können natürlich passieren. Aber genau deshalb hat man ja Sicherheitsmechanismen. Die sollen nicht nur böse Buben abhalten, sondern auch Fehlerauswirkungen einschränken.

 

[Kuristina]

Ich finde ja ohnehin spannend, das Themes Shellbefehle absetzen können bzw. überhaupt Zugriff aufs Dateisystem haben

Das wundert mich auch. Damit würden für mich schon mal alle Themes rausfallen, die nicht von mir sind. ^^

Ich hätte mal vermutet, das das mehr oder weniger nur Style-Sheets plus ein paar Grafiken sind

Genau. So ist das mit gtk.

 

[rallyco]

Vielleicht hatte es doch was Gutes, dass ich neue Themes erstmal in VMs oder auf einem Wegwerfsystem teste

 

[EdwinOdesseiron]

Ich weiß nicht warum, aber ich bin mit dem Breeze (Light) bzw. der OpenSuse-Variante sehr zufrieden, weshalb ich mir noch nie ein Alternatives Theme installiert habe.
Icons habe ich schon mal geändert, bin aber auch immer auf die Standardvariante zurückgegangen...

 

[andy_m4]

Vielleicht hatte es doch was Gutes, dass ich neue Themes erstmal in VMs oder auf einem Wegwerfsystem teste

Wobei ein einfacher Sandbox-Mechanismus ja schon wäre, für sowas einen eigenen User-Account anzulegen.
Das kann man noch damit ergänzen, in dem man dann aufs (beschreibare) Home-Verzeichnis einen "Wegwerf-Layer" drauf macht. Oder wahlweise auch mit Snapshots arbeitet, falls das Dateisystem das anbietet.

 

[sedot]

Ich hätte mal vermutet, das das mehr oder weniger nur Style-Sheets plus ein paar Grafiken sind.

Oh sweet summer child. 😅

Als Beispiel vielleicht Breeze, das Standard-Theme von Plasma 6.
https://invent.kde.org/plasma/breeze/-/tree/master?ref_type=heads
Color Schemes, Cursor, Fenster(-Titelleisten) und Anwendungsstil plus Wallpaper.

Wenn du dann noch (Community) Themes anschaust wirst du sehr viel Komplexität für Details finden.
Zwei random Beispiele, die ich auch mal in Verwendung hatte mit Plasma 5;
https://github.com/paulmcauley/klassy/tree/plasma5.27?tab=readme-ov-file
https://github.com/kupiqu/SierraBreezeEnhanced

Zumindest in Plasma 6 hatte ich neulich einen Hinweis zu Gefahren gesehen in dem Fenster von dem externe Themes geladen werden können. Wie lange es dieses Banner schon gibt weiß ich nicht.

GTK ist auch nicht weniger komplex - gerade dann wenn hohe Uniformität im look and feel angestrebt wird.

Aber wenn das was Du beschreibst möglich ist, dann ist dann würde ich das als Sicherheitslücke deklarieren.

Sehe ich auch so. Perspektivisch muss/sollte KDE schauen ob der Store nicht mehr reglementiert werden sollte. Ist natürlich eine schwierige Situation, weil Plasma für leichte und umfangreiche Anpassung steht.

Aber genau deshalb hat man ja Sicherheitsmechanismen. Die sollen nicht nur böse Buben abhalten, sondern auch Fehlerauswirkungen einschränken.

Ja, hier ist ein sehr grundsätzliches Problem – wo sind die Grenzen von Freiheit und Sicherheit?
Ich bin gespannt wie KDE und die Community damit umgeht. Werden die Hinweisbanner größer oder gibt es einen strenger kontrollierten Store?

Oder wahlweise auch mit Snapshots arbeitet, falls das Dateisystem das anbietet.

Ich weiß nicht ob z.B. snapper so umfangreich wiederherstellen kann, zumal /home ohnehin afaik default kein Teil der Snapshots ist. Das was der User auf reddit berichtet ist ohne Backup wirklich ärgerlich und noch tragischer wenn gerade ein Backupmedium am Rechner hängt.

 

[andy_m4]

Ja, hier ist ein sehr grundsätzliches Problem – wo sind die Grenzen von Freiheit und Sicherheit?

Ja. Das ist natürlich immer ein Balance-Akt. Aber die grundsätzliche Problematik ist ja nicht neu. Das hat man ja bei anderen Add-in-Systemen auch.
Sowas wie Dateisystemzugriff, Netzwerkzugriff und Execution würde ich aber immer generell als sensibel ansehen.
Wenn man das trotzdem braucht, könnte man ja als Kompromiss zumindest eine Warnmeldung bringen, wo man dann angefragte Rechte gewähren kann oder auch ablehnen.

Werden die Hinweisbanner größer oder gibt es einen strenger kontrollierten Store?

Das mit dem kontrollieren bindet halt auch Ressourcen. Außerdem hast Du dann auch eine Verantwortung. Wenn du sagst "was in meinem Store ist, ist geprüft und nicht schädlich" und dann rutscht doch mal was durch, ist das halt doof.

und noch tragischer wenn gerade ein Backupmedium am Rechner hängt.

Ja. Wobei das ohnehin keine gute Backup-Strategie ist, wenn Du als normaler User aufs Backupmedium schreiben kannst.
Klassischerweise hatte man ja auf einem UNIX-System einen separaten User für (so was wie operator). Und Idealerweise ist ein Backup auch immer (auf Rechteebene) Append-Only, damit alte (intakte) Backups nicht manipuliert werden können.
Unter Windows kennt man das ja auch, das man nicht einfach seine Backup-Medium dranhängen soll, weil das im Fall des Falles mit "weggeramsomwared" wird. :-)

 

[sedot]

Wenn man das trotzdem braucht, könnte man ja als Kompromiss zumindest eine Warnmeldung bringen, wo man dann angefragte Rechte gewähren kann oder auch ablehnen.

Die Rechte müssten dann vor dem Start der Plasma Session und des Display Managers gewährt werden. Ich denke es würde nicht lange bis zum „allem vertrauen, immer“ Dialog-Button dauern.

Das mit dem kontrollieren bindet halt auch Ressourcen. Außerdem hast Du dann auch eine Verantwortung.

Ja, klar, nur irgendeine Lösung muß gefunden werden. Einen geschlossenen Store wie bei Apple wird es eher nicht geben, so offen wie es jetzt ist hat ebenso Nachteile.
Um mal anderswo zu schauen. Gnome hat eine Versions abhängige Kompatibilität für Extensions, springt Gnome in der (Major-)Versionsnummer fallen alle Extensions mit niedrigerer Versionsnummer raus und funktionieren nicht mehr.
In ähnlicher Form könnte das eine Lösung für den Plasma Store sein. Auch wenn es für einzelne User ärgerlich ist, die genau dieses Theme oder Widget mögen. Vielleicht hat aber auch die KDE Community eine bessere Idee.

Wobei das ohnehin keine gute Backup-Strategie ist, (…)

Ja, weiß ich und die Nachteile sind mir bekannt. Danke für die ergänzenden Hinweise. 🙂

 

[andy_m4]

Die Rechte müssten dann vor dem Start der Plasma Session und des Display Managers gewährt werden.

Die könnten auch bei der Installation angefragt werden. Genauso wie man es z.B. bei der App-Installation unter Android hat.

 

[Pummeluff]

Die Strategie der Distributionen ist schon erstaunlich.

• Arch: Da war die 6.0.2 schon vor knapp 2 Wochen raus.
• Bei Gentoo ist die 6.0.2 maskiert, d.h. noch nicht mal Testing. Stable ist die 5.27.11
• Und Fedora, was sonst immer Bleeding Edge ist, bietet mir auch nur die 5.27.11-1 an

 

[Mickey Cohen]

Fedora ist kein rolling Release und wartet bei major versionsupdates von komponenten öfter Mal auf das neue distro-release.

 

[sedot]

Die könnten auch bei der Installation angefragt werden.

So handhabt es Flatpak per CLI. Auflistung, generelle Zustimmung oder Ablehnung der Installation. Graduelle Anpassung gibt es nicht im Prozess. Aber auch dann, wenn auf Datenträger zugegriffen werden darf wäre meine Annahme als Nutzer nicht der unmittelbare Datenverlust.

Android

Irgendwer muss Auskunft geben, entweder der Entwickler oder der Betreiber des Stores. Die vertrauenswürdigere Instanz wäre aus meiner Sicht der Betreiber, womit ein höherer Aufwand für KDE einherginge. Es sind nicht nur technische Aspekte wesentlich sondern auch der Content selbst, Copyright als Beispiel.

Die Strategie der Distributionen ist schon erstaunlich.

Ich denke manpower spielt auch eine Rolle, Maintainer von Distributionen kümmern sich in ihrer Freizeit und nicht hauptberuflich. Eine Bringschuld gegenüber Usern besteht nicht.

 

[andy_m4]

generelle Zustimmung oder Ablehnung der Installation

Na es geht mir nicht um die Ablehnung der Installation, sondern das vergeben von Rechten. Selbst wenn man die angeforderten Rechte nicht einräumt, kann ja die Installation durchaus durchlaufen. Das Theme funktioniert dann vielleicht nicht so wie erwartet. Dann könnte man sich im nachhinein aber immer noch überlegen, ob man die Rechte doch noch einräumt (genauso wie man unter den App-Einstellungen bei Android ja auch im nachhinein noch Berechtigungen vergeben oder entziehen kann).
Ich könnte mir auch gut vorstellen, das man sich auf Wunsch auch anzeigen lassen kann, was denn genau wo hin geschrieben werden soll.

Aber auch dann, wenn auf Datenträger zugegriffen werden darf wäre meine Annahme als Nutzer nicht der unmittelbare Datenverlust.

Erst mal gehe ich davon aus, das kaum ein Theme wirklich weitreichende Zugriffsrechte braucht. Das wäre dann ja ohnehin nur die Ausnahme, wenn dann welche angefordert werden weil das Theme halt besondere Dinge macht. Und dann kann man sich immer noch genau überlegen, ob man das für den speziellen Fall haben will oder nicht.

Die vertrauenswürdigere Instanz wäre aus meiner Sicht der Betreiber, womit ein höherer Aufwand für KDE einherginge.

Zunächst einmal soll ja die Runtime die die Themes dann letztlich umsetzt, die Zugriffsrechte überwachen. Was die Themes an Zugriffsrechten braucht, kann natürlich am besten der Entwickler wissen und entsprechend hinterlegen.
Damit wäre der Store komplett raus, was das Zugriffsrechten-Thema angeht.

Es sind nicht nur technische Aspekte wesentlich sondern auch der Content selbst, Copyright als Beispiel.

Ja gut. Das Problem hast Du ja schon jetzt. Das wird ja durch die Forcierung von Zugriffsrechten nicht verändert.