Was eben auf Grund der schwierigen Unterscheidbarkeit ja auch meistens der Fall sein wird.
DIe Wiederherstellung ist ein Zusammenspiel des Session Managers und der Anwendungem-
Der Session Manager hat eine Liste von Anwendungen, die zur Sitzung gehören sollen und startet diese unter Übergabe spezieller Parameter, u.a. eine Session ID (eine generierte Zeichenfolge, die der Anwendung auch bei der Speicherung zugeteilt wurde).
Die Anwendungen wissen daher, dass sie wiederhergestellt werden und welchen ihrer potentiell mehrfachen Zustände dabei zu berücksichtigen ist (eine Applikatoon kann je mehrmals in der Sitzung vorkommen).
Ob die Anwendung irgendwelche Daten gespeichert hat, sie erfolgreich lädt und wiederherstellt, ist dann in deren Verantwortung.
For Plasma, bzw KWin, ist unter X11 nicht feststellbar, ob ein neues Fenster Teil eines Wiederherstellungsprozesses ist oder gänzlich neu.
Unter Wayland wird das eben anders gehandhabt werden und die Anwendungen teilen ihrerseits bei Wiederherstellung von Fenstern mit, zu welcher Session ihre jeweiligen Fenster gehört haben.
KWin kann damit seinerseits Daten laden und anwenden.
Es würde auf jeden Fall auch Änderungen in den Anwendungen benötigen, damit diese ihre Fenster dem entsprechendem Sitzungsprofil zuordnen.
Was eben im neuen Wayland Protokoll bereits vorgesehen ist. Für X11 hätte man eine Protokollerweiterung machen können, aber dei Frage war da sicher, ob sie dann von Anwendungen bzw deren Frameworks auch umgesetzt worden wäre.
Wenn ich die Erwähnung in einer der wöchentlichen Zusammenfassungen richtig interpretiere, wird Plasma 6.4 eine Vorabversion der “Serverseite” haben.
GNOME’s Mutter hat das wohl auch bereits , auch einige Anwendungen und vermutlich auch GTK bzw Qt.
Ich habe eine KWin Fensterregel, die zur Anwendung kommt, wenn KMail’s Hauptfenster erstellt wird.
In dieser Regel setze ich Desktop 2 und “Alle Aktivitäten”. Dsa entspricht im Prinzip dem letzten Zustand, unabhängig davon, ob ich das Programm manuell, über Autostart oder Session starten würde.
Ich finde das sehr praktisch, da ich mehrere Fenster an gewissen Positionen erwarte und damit bekomme.
Ja, man hätte hier den Ersteller darauf hinweisen können, dass Plasmashell das falsche Adressat ist und entsprechende Tickets für die betroffenen Anwendungen gemacht werden müssten.
Dann hätte jeder weitere Betroffene diese Information vorgefunden und es wäre nicht der Eindruck entstanden, dass es sich um einen Fehler von Plasma handelt.
Ich würde jetzt davon ausgehen, dass die oben erwähnte Umsetzung auch die Zuordnung zu Aktivitäten berücksichtig.
Vielleicht habe ich im Laufe der nächsten Tage mal Zeit, den Code zu inspizieren.
Ausgezeichnet!
Je präziser das Prblem eingegrenzt werden kann, desto leichter lässt sich meistens die Ursachen finden.
Normalerweise wird der Report geschlossen, wenn die entsprechenden Änderungen eingeflossen sind.
Ausnahmen sind vielleicht Fälle, in denen der Entwickler den Fehler selbst nicht reproduzieren kann und damit Bestätigung der Betroffenen abwarten muss.
Wie gesagt hätte hier der Bug geschlossen werden können, da er ja gar nicht an dieser Stelle zu beheben war.
In anderen Fällen werden Reports leider auch oft “Waisen”, ihre Ersteller nicht mehr erreichbar oder vergessen, sie aktuell zu halten.
Dann fällt es auf die Helfer zurück, die Bug Triage machen, das zu tun, und deren Zeit ist auch begrenzt.