The main reason why we have factory methods is that up to some point,
kwayland had its own signal to indicate when globals have to be removed.
Now that all globals add destroy listeners for the wl_display object,
we don't have that signal. Most factory methods are equivalent to doing
new T(display).
Besides adding unnecessary boilerplate code, another reason to get rid
of the factory methods is to reduce the amount of merge conflicts. If
several persons work on implementing wayland protocols at the same time,
sooner or later someone will have to resolve merge conflicts in Display.
Summary:
Some of the documentation did not say what the purpose of the
respective class was, but rather gave a tautology.
For people new to the code base it helps to mention that
DPMS is power management.
That DataDevice is for copy-and-paste and drag-and-drop is
maybe obvious to people used to X11 API, but not very clear
to most others.
When first reading the KWayland code, some explanations
help getting around.
Reviewers: #kwin, romangg
Reviewed By: #kwin, romangg
Subscribers: romangg, zzag, kde-frameworks-devel
Tags: #frameworks
Differential Revision: https://phabricator.kde.org/D23915
Adding support for a org_kde_kwin_dpms interface. On server side
Dpms is mostly bound to the OutputInterface exposing just a very
small manager. Whether Dpms is supported and which mode is used is
tracked directly on the OutputInterface.
