Beiträge von adler53

Beim Versuch, über die Systemeinstellungen (hier Punkt "Starten und Beenden" ) ein Hintergrundbild festzulegen oder zu ändern, passiert nichts.
Zwar ist das neue Bild in der Vorschau enthalten, aber beim Neustart bleibt das letzte Bild.

1. Man könnte die Konfigurationsdatei ausfindig machen, und - soweit die Konfiguration nicht als HexCode verschlüsselt ist - mit der Hand ändern. Dazu brauche ich aber die Datei.
2. Eine Analyse des Programmlaufs, um zu sehen, warum das Hintergrundbild immer beim Alten bleibt.

Ich würde eher zu 1 neigen, da sddm ja regelmäßig upgedatet wird und der Fehler möglicherweise immer noch drin sein könnte.

Wer kennt die sddm - Konfigurationsdatei , wo das Hintergrundbild (bzw. der Verweis auf das Hintergrundbild) eingestellt wird.

Nach einem Update am 7. Februar bekam ich keine Verbindung mehr zu sddm.
Anstelle des Greeters (bzw. der Anmeldemaske) bekam ich einen weißen Bildschirm.
Das Problem hängt mit einigen "broken drivers" zusammen und lässt sich so lösen:

Die Cache-Verzeichnisse aus der Root-Konsole löschen und zwar:
/home/User/.cache und
/var/lib/sddm/.cache

Danach mit init6 Neustart! Danach sollte der Greeter bzw sddm wieder erscheinen und ordnungsgemäß funktionieren !!

Bei mir funktionierte KDE-Plasma einmal auf folgende Weise nicht:

1. Amarok, das gerade im Hintergrund Musik spielte, fing an, sich zu benehmen, als würde eine Schallplatte mit defekter Rille abgespielt. Dann setzte der Ton aus.
Ich konnte nur noch den Mauszeiger bewegen, kein Tastaturbefehl außer CTRL+ALT+F1 funktionierte, von der eingefrorenen Grafik zu schweigen. Und selbst der Wechsel auf die ROOT-Konsole wurde erst nach einer Minute ausgeführt.
Gleichzeitig klapperte die Festplatte wie die Mühle am rauschenden Bach.

2. Ein Versuch, über die Root-Konsole Zugriff auf mein System zu bekommen, scheiterte beim ersten Mal mit einem Timeout nach 60 sec.
3. Beim zweiten Login-Versuch (nach 16 min. wurde das Klappern der Festplatte langsamer) konnte ich mich einloggen.
4. Der Konsolenbefehl top lieferte mir die Information, daß ein Job namens kswap0 auf der Platte übereifrig operierte, so daß das System total überlastet war.
5. Nach dem ich vorsorglich shutdown -r 15 eingegeben hatte, wechselte ich mit CTRL+ALT+F7 zu Plasma zurück.
6. Mittlerweile lief die Musik wieder, aber ich konnte nichts mehr machen, auch der Mauszeiger machte keine Bewegung mehr, die Fenster blieben eingefroren.
7. Nach weiteren 15 Minuten startete das System neu (siehe Punkt 5).

Man sollte beim Einfrieren von Plasma immer auch mal hören, ob die Festplatte extrem stark beschäftigt ist. KDE-Plasma reizt das System bis zum letzten aus, so daß man
sich nicht wundern muß, das es nur noch auf der neuesten Hardware dauerhaft "betriebsfest" ist.
Denn so was, wie oben geschildert, habe ich bei Cinnamon, XFCE und dem als RETRO verschrienen TRINITY niemals beobachten können.

Was ist mit den Hintergrundprogrammen zur schnellen Desktop-Suche, wie BALOO ? Auch die verlangen der Hardware ordentlich etwas ab und schaufeln ordentlich Daten "im Dreieck"!
Bei den alternativen Desktops kommt es auch mal gelegentlich zu einem kurzen Systemstillstand, der aber nicht mehr als eine Sekunde dauert. Dann geht es wieder weiter....
Dieses Problem mit KDE-Plasma besteht bei mir schon seit Version 5.4.xxx

Habe eine andere Lösung gefunden !
Auf der Downloadseite von FreeCAD fand sich die Möglichkeit, ein AppImage herunterzuladen.

https://github.com/FreeCAD/Fre…glibc2.17-x86_64.AppImage

Dies habe ich dann in ein Verzeichnis gepackt und ausführbar gemacht.
Nach dem Aufruf dieses Images wurde ich gefragt, ob ich dieses Image ins System einbinden wollte und Icons erstellen lasse.
Nachdem die "Installation" erfolgt war, startete FreeCAD. Die Draft und Arch - Funktionen funktionieren jetzt einwandfrei.
Nur der Programmaufruf ist jetzt anders.
Ist wohl die bessere Alternative !

Näheres auf https://de.wikipedia.org/wiki/AppImage

Manchmal aktualisiert man ein Softwarepaket und stellt fest, dass es nicht mehr oder teilweise funktioniert. In meinem Falle gilt dies für FreeCAD.
Es ist von Python bzw. pivy abhängig und arbeitete bis etwa Ende Oktober noch einwandfrei. Dann fielen 2 Funktionen aus, weil pivy nicht vorhanden sein sollte.
Aber es war unter Opensuse bzw. Python vorhanden.
Nur arbeitet FreeCAD - wie unter UBUNTU - mit einem internen pivy, das aber - wenn man FreeCAD mit zypper oder yast bzw. mit 1-click-install installiert - nicht unter OpenSuSe
installiert wird.
Aus dem FreeCAD - Forum geht hervor, das man verschiedene Randbedingungen korrekt setzen muss, um FreeCAD vollständig am laufen zu kriegen.
Wenn aber eine korrekte Installation mit den "Bordmitteln" von OpenSuse (zypper, Yast und co.) nicht möglich ist, könnte man eigentlich diese Software aus dem Bestand
entfernen und die Interessenten darauf hinweisen, daß man FreeCAD ausschließlich aus den Quellen installieren sollte und sich die Randbedingungen aus der Fachliteratur bzw einschlägigen Foren besorgen sollte.
Vielleicht müsste manches Softwarepaket sogar geforkt werden, damit auch andere Distributionen zum Zuge kommen.

Das obengesagte gilt für jedes Softwarepaket, dass eigentlich nicht für Opensuse, sondern für eine anders strukturierte Distribution programmiert wurde und mit den "Bordmitteln" von Opensuse nicht
korrekt eingerichtet werden kann.

P.S. Ich habe FreeCAD binär unter Ubuntu (virtuell mit qemu) und als WINDOWS-Version m.H. von Wine installiert; beide laufen unter diesen Umgebungen einwandfrei.

Bei Opensuse gefällt mir, dass man eine große Auswahl hat, welchen Windowmanager man haben will. Man kann auch mehrere nebeneinander installieren.

Plasma gefällt mir am Besten, weil es vom äußeren Erscheinungsbild sehr ergonomisch ist und darüber hinaus noch gut anpassen läßt. Mehrere Aktivitäten gleichzeitig zu haben,
zwischen denen man wechseln kann, ist auch ein Vorteil. Wenn ich geöffnete Dateien nicht in der unteren Leiste haben will, sondern am rechten Bidschirmrand; bei Plasma kein Problem.
Nachteilig sind die ständigen Systemstillstände, die mich dann zum Abbruch und Neustart zwingen. Welchen Grund dies hat,
müsste von jemanden ermittelt werden, der In Punkto Programmierung einen Mastergrad besitzt.
Denn KDE-Plasma ist schon sehr überfrachtet und verbraucht viel Arbeitsspeicher. Das KDE-Team scheint sehr die Entwicklungspeitsche zu schwingen, sonst gäbe es nicht so viel Fehlerquellen.

Cinnamon ist auch ein guter Partner, der zwar einfacher gebaut ist, aber trotzdem sehr stabil geworden ist. Ich benutze diese Oberfläche immer, wenn ich wegen der Systemstillstände von Plasma
genervt bin. Etwas nachteilig ist, daß man - wie bei Gnome und seinen Forks - nicht so große Freiheit hat (insbesonders bei der Gestaltung von Leisten). Es wäre allerdings ein guter Einstieg für
Wechsler aus Windows/ Redmond. Und ergonomisch ist Cinnamon auch.

Xfce ist für mich etwas bescheidener, aber auch eine gute Wahl.
Weil es so bescheiden ist, habe ich noch nie Systemstillstände gehabt, wie bei Plasma. Hier kann man bei der Einrichtung der Leisten sogar noch mehr improvisieren.

Trinity ist auch nicht schlecht, mit seinem Vorbild KDE 3.15 habe ich stets gute Erfahrung gemacht, allerdings halte ich (subjektiv gesehen) XFCE für ein besseres KDE 3.15 mit noch einigem dazu.

Und *-alternatives läßt sich auch mittels yast bzw. yast2 modifizieren (yast alternatives) wodurch die ganze Sache interaktiver und ergonomischer wird.

Was mich noch interessieren würde, das wären Handbücher/Docs zu der ganzen update-* Familie, nicht nur update-alternatives.
Kann jemand einen Tip geben, wo mehr zu dem Thema zu finden ist als in den .doc , Readme-Files oder man-Seiten ?
Hat jemand einen Tip ?

Der Befehl update-alternatives --config displaymanager soll jetzt sysconfig ersetzen; Er war bei der "falschen" Einstellung auf einem ominösen "auto-mode".
Ich habe ihn auf LightDM und "manual" geändert, damit ist das Problem gelöst !

Danke tomfa-ng !
Allerdings heißt der Befehl jetzt in der aktuellen Version:
update-alternatives --config default-displaymanager


Wer über yast services den Dienst sddm auf aktiv und on gesetzt hat, muß ihn vorher auf off und deaktiviert stellen.

Natürlich nicht !

Aber etwas anderes !
Ich habe über yast sw_single das Änderungsprotokoll von gdm eingesehen. Dabei fiel mir folgender Eintrag auf:

Mi 18 Okt 2017 14:00:00 CEST
xwang@suse.com
- Add gdm-ignore-duplicate-session.patch: Fix gdm session entries
  duplicate (bsc#1060627).
Do 12 Okt 2017 14:00:00 CEST
dimstar@opensuse.org
- Have update-alternatives handle Xinit's integration of the
  displaymanager, replacing /etc/sysconfig/displaymanager
  (boo#1053863).
- Drop usage of glib2_gsettings_schema_* and icon_theme_cache_*
  scriptlets, since this is handled by file triggers now.

replacing /etc/sysconfig/displaymanager ! Und das sollte der Ort für die Festlegung der Window-Manager sein !
Möglicherweise hat dimstar@opensuse.org in weiser Pädagogik ein neues Verfahren per Update eingespielt und dadurch kann man auf Displaymanager und Windowmanager nicht mehr
ändernd zugreifen.

Ich muß dann noch einmal die /etc - Dateien und usr/share - Dateien vor die Brust nehmen.
Auf einem Clon meiner Festplatte sind die Verzeichnisse und Dateien auf dem Stand vor meiner Krankenhausgeschichte