Hi zusammen,

das Umbennen des .cache hat keine Veränderung gebracht. Die Ausgabe von

find ~/.config -type f -amin -3

schaut wie folgt aus:

/home/luke/.config/kalendaracrc
/home/luke/.config/gtk-3.0/settings.ini
/home/luke/.config/plasmashellrc
/home/luke/.config/plasma-org.kde.plasma.desktop-appletsrc

Die letzen beiden Dateie hatte ich ja schon versucht, die erste scheint den Kalender zu betreffen. Ich wechsel mal in den anderen User und benne die ini um, mal schauen, was dann passiert 🙂

edit: habe den Inhalt der ini-Datei des Testusers in die ini des meinigen, fehlerbehafteten geschrieben; es unterschieden sich zwei Zeilen --> keine Änderung. Das Verhalten bleibt: die Icons sehen prima aus, bis man mit der Maus darüber fährt, dann verschwinden sie, bzw. werden alle auf einen Haufen geschoben.

Habt Ihr noch Ideen?

Die /home/luke/.config/gtk-3.0/settings.ini dürfte nichts mit Plasma zu tun haben.
Für gewöhnlich wird da z.B. das theme von GNOME Anwendungen festgelegt.

Hast du schon mal die Tasbar von luke komplett gelöscht und mal eine neue angelegt?

Ansonsten hätte ich noch folgende Idee:
Annahme:
Die beiden plasma-config-Dateien die wir gefunden haben verursachen es nicht.
Irgendeine eine alte plasma Einstellung überlagert deine Einstellungen.
Das finden wir aber so nicht heraus.
Ausführung:

  • Log dich unter dem neuen Benutzer oder tty ein.
  • Lösche alle alten plasma configs vom User luke
    # find /home/luke/.config -type f -name "plasma*" -exec rm {} \;
  • Beim Einloggen von luke müsste Plasma dann alle Dateien die es benötigt mit den default Einstellungen selbstständig wieder herstellen.

Risiko:
Das Risiko dürfte begrenzt sein. Es werden nur Dateien unterhalb von /home/luke/.config die mit dem Namen plasma beginnen gelöscht. Wenn ein neuer user angelegt wird, muss Plasma auch alle diese Dateien neu erstellen. Alle Einstellungen die nicht zu Plasma gehören bleiben davon unbehelligt.

Alternativ könntest du auch mit # find /home/luke/.config -type f -name "plasma*" und
# find /home/<neuer user>/.config -type f -name "plasma*" Datei für Datei durchgehen und mit einander inhaltlich vergleichen.
Dann findest du eventuell den Fehler aber der Aufwand ist ungleich höher.

  • _Ardbeg_ hat auf diesen Beitrag geantwortet.

    Was zusätzlich runtergeladene alternative Themes betrifft sollte man ohnehin sehr vorsichtig sein.
    https://linuxnews.de/vorsicht-bei-kde-global-themes/

    Bei dem Hinweis den du gefunden hast, da geht es ja speziell um das upgrade von breeze auf die aktuelle version. "Verschwinden der Icons" genau das könnte den Fehler verursachen der bei @_Ardbeg_ auftritt. Das würde ich auf jeden Fall einmal versuchen.

    Interessant ist auch der Punkt 4.6.1. im Grunde ist hier das gleiche Vorgehen beschrieben, dass ich vorgeschlagen habe.

    Hi zusammen,
    zunächst mal wieder vielen Dank für die Unterstützung. So langsam glaube ich, dass wir an der falschen Baustelle arbeiten...
    Zunächst habe ich entsprechend des Links von GerBra alle Einstellungen unter "Farben & Designs" zunächst umgestellt, übernommen und wieder zurück --> keine Änderung
    Bezüglich alternativer Themes kann ich auch Entwarnung geben, verwende nur das Standardzeugs, für mich ist die Auswahl ausreichend 😉
    Dann habe ich vom testuser aus alle Dateien entsprechend des Befehls

    tuxnix # find /home/luke/.config -type f -name "plasma*" -exec rm {} \;

    entfernt, auch das brachte keine Änderung.

    Was könnte man noch versuchen?

    Edit: Noch was: seit dem selben Update kann ich Firefox reproduzierbar abschießen, wenn ich es durch Schieben an eine Seite über diese Einrastfunktion auf die halbe Bildschirmbreite bringen will. Dabei kommt im Systemtray die Nachricht, dass kwin-wayland abgestürzt sei. Kann das zusammenhängen?

      Der Firefox-Absturz hat m.M.n. nichts damit zu schaffen.

      Nur noch mal zur Nachfrage:

      • Hast du den Benutzer nach dem Ändern von den Systemeinstellungungen auf ein anderes icon-set neu angemeldet? System Settings > Colors & Themes > Global Theme > Icons

      • Hast du den find...rm Befehl mit root Rechten ausgeführt? (Klar sonst kommt eine Fehlerausgabe)

      Dann fällt mir jetzt nur noch folgendes ein:

      • In den System Settings würde ich auch die Desktop-Effekte komplett ausschalten.
        System Settings > Workspace Behavior > Desktop Effects

      • Dann würde ich eingelogged als luke mal die Umgebungvariabe auf der Konsole abfragen
        printenv QT_QPA_PLATFORMTHEME
        Wenn dort keine Meldung erscheint ist es richtig.

      • Und dann fällt mir nur noch ein, dass du auch mit dem neuen user Account weiterarbeiten könntest. Wenn man die anderen Einstellungen sukzessive dahin kopiert, findet man auch den Fehler.
        Oder du kopierst zunächst einmal den gesamten .config Ordner dorthin. Im Zweifelsfall kannst du ja wieder einen neuen user anlegen. Aber man weiß dann effektiv mehr.

      Hi zusammen,

      habe es gerade wieder hingebogen 🙂
      Zunächst habe ich mal den .config Ordner des Testusers nach luke kopiert, inkl. Rechteanpassung.
      Dann wieder in luke eingeloggt und siehe da, das Problem war weg. Dafür aber war irgendwie mein home-Ordner "hart" mit meinem Desktop verdrahtet. D.h. ich hatte alle Ordner und Dateien aus/home/luke/ auf dem Desktop.
      Das ging natürlich auch nicht, aber damit war klar, dass es etwas im .configsein muss.
      Bin dann durch .config gepflügt und habe einen Ordner /home/luke/.config/kdedefaults/ gefunden, der dem Namen nach sechs default Dateien enthält. Diese in .config kopiert, bzw. die vorhandenen ersetzt, neu angemeldet und siehe da, es passt wieder 😉
      Herzlichen Dank an alle für die Unterstützung, vor allem tuxnix - ohne Eure Hilfe wäre ich nie zu der Lösung gekommen!
      VG

      luke

      _Ardbeg_ Dabei kommt im Systemtray die Nachricht, dass kwin-wayland abgestürzt sei. Kann das zusammenhängen?

      Das führt noch mal zur Frage anfangs des Threads, ob du nun XOrg oder Wayland nutzt. Was ja von @agarbathi und Josephus Miller angesprochen wurde. Ebenso die neue Default-Einstellung zugunsten von Wayland.

      Was sagt bei dir aktuell:
      env | grep -i wayland
      und
      env | grep -i -e xorg -e x11
      Wenn beim ersten Befehl z.B. $XDG_SESSION_TYPE wayland anzeigt, dann läuft plasma bei dir unter Wayland.

      Das wäre wichtig für dich zu wissen bei zukünftigen Problemen/Entscheidungen, da Wayland oder XOrg ganz unterschiedliche Probleme/Herangehensweisen/Möglichkeiten mitbringen.

      • _Ardbeg_ hat auf diesen Beitrag geantwortet.

        GerBra Was sagt bei dir aktuell:
        env | grep -i wayland

        Ausagabe:

        [luke@meinRechner ~]$ env | grep -i wayland
        XDG_SESSION_TYPE=wayland
        WAYLAND_DISPLAY=wayland-0
        QT_WAYLAND_RECONNECT=1

        GerBra und
        env | grep -i -e xorg -e x11

        Ausgabe:

        nichts 🙂

        Ich interpretiere das nun doch so, dass Wayland läuft. Kann das automatisch umgestellt worden sein? Meine Installation ist schon acht Jahre alt oder sowas und ich meine mich zu entsinnen, dass ich was mit X11 aber nichts mit wayland gemacht hatte...

        Ein Problem mit dem Fenstermanager würde auch zu

        _Ardbeg_ Edit: Noch was: seit dem selben Update kann ich Firefox reproduzierbar abschießen, wenn ich es durch Schieben an eine Seite über diese Einrastfunktion auf die halbe Bildschirmbreite bringen will. Dabei kommt im Systemtray die Nachricht, dass kwin-wayland abgestürzt sei. Kann das zusammenhängen?

        passen. Das ist nämlich nun auch gefixt.

        Ich lerne zwei Dinge:

        1. Wenn ich nicht sicher bin, eine Frage einer Helfenden richtig beantworten zu können, lieber nochmal nachfragen, bevor man die Geschichte in eine falsche Richtung lenkt.
        2. Auch wenn die Frustration steigt, weiter fleißig Backups von Dateien und Ordnern machen, die man überschreibt. Das habe ich leider beim Einfügen der Defaultdateien nicht gemacht. Mein System funktioniert zwar wieder, aber leider werde ich nie erfahren, was genau der Grund war...

          _Ardbeg_ Kann das automatisch umgestellt worden sein?

          Wie ich dir schrieb: Ja

          Josephus Miller Beim Update wurde nämlich Wayland mit installiert und als Standardsitzung aktiviert.

          Ich nehme an, dass du seit dem update mit wayland unterwegs warst.
          Einstellen kann man das vor dem Einloggen. Im Login-Manager SDDM gibt es links unten ein menue zum aufklappen mit dem man das einstellen kann.
          Dein Post mit pacman -Qi xorg-xinitsagte lediglich aus, dass du das Paket xorg-xinit installiert hast, aber nicht ob deine Sitzung auf X11 lief.
          Die Fehlermeldung von kwin-wayland zeigte dann, dass du mit wayland unterwegs warst.
          env ...dann auch.
          Es wäre interessant gewesen auszuprobieren ob der Fehler auch in einer X11 Sitzung auftaucht wäre.
          Aber wenn es jetzt gut ist, dann ist es auch gut. 😉

          _Ardbeg_ Ich interpretiere das nun doch so, dass Wayland läuft.

          Ja, aus den Gründen, welche die Vorposter genannt haben.

          Für dich als KDE/Plasma-User ist das "dreckige Maschinendeck" unterhalb eigentlich unwichtig, du hast es ja selbst nicht mal gemerkt. Es hat aber - deshalb mein Nachhaken - Auswirkungen für deinen Umgang mit etwaigen "Problemen".
          Z.B. kannst/brauchst du nichts mehr in /etc/X11/* oder per xorg.conf(-Schnipsel) bzgl. Dinge wie Grafikkarte/Monitor/Schriften/etc. einzustellen, auch ein XOrg.<DISPLAY>.log gibt es nicht mehr bzw. hat keine Aussagekraft (Diese Aussage mit Vorbehalt, da ich nicht weiß welchen Einfluß xwayland hat).

          Gerade im englischen Archlinux-Wiki gibt es ja für viele Anwendungen/Verfahren am Ende die "Troubleshooting"-Sektion. Und gerade dort finden sich eben viele Dinge/Tips, die eben nur eine Rolle spielen wenn entweder Wayland oder XOrg verwendet wird.
          Insofern ist es für dich doch wichtig zu wissen, wer auf deinem "Luxusdampfer im Maschinendeck schuftet <g>".

          "Zweiter User zum Testen"
          Ich empfehle dieses "Konzept" sehr oft, da sich so viele Dinge ohne großen Aufwand austesten lassen.

          • Dieser ist einfach anzulegen und genauso einfach wieder zu löschen und wieder anzulegen
          • Es läßt sich grob ermitteln: Liegt die Ursache eines Problems eher in $HOME oder /etc
          • Dinge, die ich für meinen User/Desktop/Windowmanager ausprobieren möchte lassen sich so ohne Veränderungen in irgendwelchen Configs meines Users austesten.
          • Als KDE/Gnome-User hätte ich wohl einen Testuser den ich bemühen würde wenn, wie gerade die letzten Tage, bei "meiner" Desktopumgebung ein großes Update ansteht (Sieht bzw. kann man ja sehen bei den Anzeigen seines Paketmanagers. Erst wenn bei meinem Testuser nach dem Update das Grundlegende noch funktioniert würde ich meinen Normaluser starten. Falls nicht, kann ich immer noch Dinge rückgängig machen("Downgrades") oder andere Maßnahmen treffen("Backups") bevor Konfigurationen im $HOME des Normalusers verändert werden.
          • _Ardbeg_ hat auf diesen Beitrag geantwortet.

            GerBra
            Vielen Dank für die nette Umschreibung mit "dreckiges Maschinendeck" und "Luxusdampfer" 🙂
            Ich nutze jetzt Archlinux seit acht oder neun Jahren ausschließlich und immer noch mit der ersten Installation, habe sicher schon das ein oder andere gelernt aber naheszu alles aus dem "Maschinenraum" ist mit über die JAhre nicht wirklich verständlicher geworden - möglicherweise liegt es an der geringen Frequenz der Probleme und/oder der - wie ich finde - immer tollen Hilfe hier im Forum.
            Den Testuser lasse ich mal leben; die nächste Notwendigkeit ihn zu nutzen kommt bestimmt 😉

            Schöne Ostern Euch allen!