The current KScreenLocker expects the Compositor to hand over the
This has several disadvantages:
- In KScreenLocker functionality is duplicated which the compositor probably has setup already (creating client connections manually).
- The Display object has a way larger scope than what KScreenLocker actually needs.
- Ownership of the Display is unclear in regards to memory but also what the compositor is still allowed to do in comparision to KScreenLocker with the Display.
- KScreenLocker can only be integrated in compositors using KWayland for managing their wl_display protocol object.
Instead it is now enough to hand over a single file descriptor KScreenLocker
can use as its client endpoint to talk to the compositor.