Architecture / Modularization

Posted Jan 28, 2026 17:28 UTC (Wed) by Wol (subscriber, #4433)
In reply to: Architecture / Modularization by rgmoore
Parent article: Xfwl4: the roadmap for a Xfce Wayland compositor

Eggsackerly.

The spec is to persist state from one instance of the compositor to the next. WHY the old compositor died is irrelevant to the requirement.

Cheers,
Wol

to post comments

Architecture / Modularization

Posted Jan 28, 2026 18:25 UTC (Wed) by pizza (subscriber, #46) [Link] (4 responses)

> The spec is to persist state from one instance of the compositor to the next. WHY the old compositor died is irrelevant to the requirement.

Except for the minor detail where the the sets of state needed for both situations are different.

* "restoring after a new startup" requires a list of applications (including command line used to launch things) and the state consists of application X instance Y window Z ==> position/size" (and almost nothing else). And of course the applications themselves need to be able to pick up where they left off, which may or may not be technically feasible or desireable. [1]

* "compositor crashed" requires is "existing connection/socket/etc ==> [a large amount of runtime compositor state]" which will necessarily require a lot more than position/size because the already-running application itself has to seamlessly recover. Notably absent is any need to know how to re-launch these applications [2]

[1] I don't need dozens of empty xterms started up for me, for example.
[2] Worth noting that the compositor probably does not even know how the application was launched (ie executable name/path/cmdline), as its first interaction with the application was when said application initiates a connection to the compositor.

Architecture / Modularization

Posted Jan 28, 2026 19:40 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

So it sounds like the state required to recover from a crashed compositor is a SUPERSET of that required to restore state after a fresh start.

So why not implement the state required to recover, and get a fresh start FOR FREE? If you have to do all that work anyway, why not take advantage of it?

Cheers,
Wol

Architecture / Modularization

Posted Jan 28, 2026 20:09 UTC (Wed) by pizza (subscriber, #46) [Link]

> So it sounds like the state required to recover from a crashed compositor is a SUPERSET of that required to restore state after a fresh start.

Uh, A+B and B+C means they share B, not that one's a superset of another.

Architecture / Modularization

Posted Jan 29, 2026 9:06 UTC (Thu) by farnz (subscriber, #17727) [Link]

No - they have very little in common (see my other comment for details). Your position is like saying that because motorbikes and planes can both get you from point A to point B, but a plane carries more people, a pilot's licence is clearly a superset of a motorbike licence.

Both have window positions. But that's all that they have in common; one has details of how to start applications and get them to create the windows you need them to create to restore state after a fresh start. The other has details of how to pretend to already-running applications that the compositor never crashed, and thus they don't have to create new windows at all.

Architecture / Modularization

Posted Jan 29, 2026 9:57 UTC (Thu) by geert (subscriber, #98403) [Link]

> [1] I don't need dozens of empty xterms started up for me, for example.

I have a script to start them for me ;-)
But as long as --geometry is a no-op on Wayland...