yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/src/wayland/CMakeLists.txt

241 lines
7 KiB
Text
Raw Normal View History

Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
set(SERVER_LIB_SRCS
buffer_interface.cpp
Adding a new ClientConnection class for wrapping wl_client The ClientConnection is managed by Display. Whenever one tries to get a ClientConnection for a wl_client* and it doesn't exist yet a new one will be created and a clientConnected signal will be emitted. Also there is a clientDisconnected signal. ClientConnection provides access to pid, uid and gid. The idea is to extend it to provide access to all the resources created for the client.
2014-11-17 15:01:18 +00:00
clientconnection.cpp
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
compositor_interface.cpp
Add implementation for wl_data_device in Server and Client On the client side anything related to wl_data_offer is not yet implemented.
2014-11-06 09:02:49 +00:00
datadevice_interface.cpp
Add DataDeviceManager and DataSource in client and server Basic implementation of the DataDeviceManager and the DataSource it creates. Still needs support for DataDevice and DataOffer to complement the API.
2014-11-04 14:10:22 +00:00
datadevicemanager_interface.cpp
Add wl_data_offer on Client and Server side Only selection part is implemented, drag'n'drop still needs to be implemented. Unit test is not properly testing whether the data can be transferred. This needs some better architecture to have multiple processes which perform the source and target part.
2014-11-06 15:56:50 +00:00
dataoffer_interface.cpp
Add DataDeviceManager and DataSource in client and server Basic implementation of the DataDeviceManager and the DataSource it creates. Still needs support for DataDevice and DataOffer to complement the API.
2014-11-04 14:10:22 +00:00
datasource_interface.cpp
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
display.cpp
[server] Add a DpmsManagerInterface 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.
2015-08-31 14:08:58 +00:00
dpms_interface.cpp
Add a base class for all server interfaces of a wl_global New base class KWayland::Server::Global which all Interface classes for a wl_global inherit. Furthermore there is a shared base class for all the Private classes of that type.
2014-11-13 14:07:31 +00:00
global.cpp
Add support for an idle time interface The idle time interface is modelled for the use cases of the KIdleTime framework to allow providing a Wayland specific implementation. It supports registering idle timeouts which are triggered on server side if there has not been any user activity on the seat for the requested amount of time. Once user activity resumes a resume from idle signal is emitted. In additon there is the possibility to simulate user activity which simulates the resume from idle.
2015-07-02 09:35:16 +00:00
idle_interface.cpp
Adding support for a fake input interface This interface allows a client to fake input events and the server might use them. There is an authentication mechanismn in place which requires the server to mark the client as authenticated in order for any events to be emitted at all. This interface is intended for use cases like kdeconnect which allows to remote control a device.
2015-07-02 19:21:57 +00:00
fakeinput_interface.cpp
[server] Move KeyboardInterface into dedicated .h and .cpp
2014-11-25 12:39:24 +00:00
keyboard_interface.cpp
server side of new outputmanagement protocol This implements the server part of the screen management protocol. The protocol is implemented as a wayland protocol. It provides the following mechanisms: - a list of outputs, close to wl_output, with additional properties for enabled, uuid, edid, etc.. These OutputDevices correspond to a connected output that can be enabled by the compositor, but is not necessarily currently used for rendering. - a global OutputManagement, which allows creating config objects, one per client. The client can make changes to the outputs through setScale(outputdevice*, scale) for example. - an OutputConfiguration resource, that can be handed to a client and used for configuration. Changes are double buffered here. Only after OutputConfiguration.apply() has been called, the changes are relayed over the global OutputManagement. The compositor is responsible to handle changes. For a more detailed description, see the API docs in especially outputconfiguration.h. REVIEW:125942
2015-11-04 14:36:52 +00:00
outputconfiguration_interface.cpp
outputchangeset.cpp
outputmanagement_interface.cpp
outputdevice_interface.cpp
Introduce categorized logging New logging categories KWAYLAND_SERVER and KWAYLAND_CLIENT.
2015-01-20 08:42:26 +00:00
logging.cpp
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
output_interface.cpp
[server] Move PointerInterface into own .h and .cpp
2014-11-25 12:52:40 +00:00
pointer_interface.cpp
[server] Add bindings for PlasmaShell interface
2015-06-09 00:48:56 +00:00
plasmashell_interface.cpp
[server] Add PlasmaWindowManagementInterface
2015-06-12 01:05:14 +00:00
plasmawindowmanagement_interface.cpp
Implementation of PointerConstraints protcol Summary: The pointer constraints protocol is an unstable protocol and thus the implementation follows the semantics of unstable protocols. The protocol allows to create a constraint on the pointer - either a lock or a confinement on a surface. Those are not activated at once, but when the compositor actively grants it. During lock no further pointer motion is emitted, during confinement the pointer is kept in a certain area. This implements T4451. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D3466
2016-11-08 13:17:15 +00:00
pointerconstraints_interface.cpp
pointerconstraints_interface_v1.cpp
Implementation of PointerGestures protocol Summary: Pointer gestures are created for a pointer and there are two types of gestures: swipe and pinch. At a given time there can only be one active gesture. The implementation in SeatInterface ensures that there can only be one active gesture. Each gesture consists of a start event, 0 to multiple update events and an end event. The end can also be a cancel. To better support this the implementation doesn't follow the protocol and splits end and cancel into dedicated methods in the server side and into dedicated signals in the client side. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D3169
2016-10-26 08:27:14 +00:00
pointergestures_interface.cpp
pointergestures_interface_v1.cpp
[server] Add support for QtSurfaceExtension protocol The Qt surface extension is a small protocol to allow exchanging additional data between QWindows and the compositor. What we are currently only interested in is the possibility to close a surface from the Compositor. Protocol description is copied from QtWayland 5.4.2 branch.
2015-06-09 22:56:31 +00:00
qtsurfaceextension_interface.cpp
Implement the wl_region interface Compositor::createRegion added which returns a Region. Also server side part is implemented.
2014-10-16 11:04:51 +00:00
region_interface.cpp
Implement support for the relative pointer protocol Summary: This change implements the zwp_relative_pointer_v1 protocol which allows to send relative motion events. The (unstable) protocol consists of a RelativePointerManager which creates RelativePointers for a given Pointer. This interface currently only has one event to report the relative motion. It carries the delta, the non-accelerated-delta and a timestamp in microsends granularity. On the server side the implementation is mostly internal. Once a RelativePointerManagerInterface is created one can send relative motion events through the SeatInterface. The SeatInterface takes care of sending it to the responding RelativePointerInterface. The protocol does not restrict the sending of "normal" and relative motion events. Thus it can be combined in any way one wants. This allows to have a rather simple implementation. A user of the SeatInterface can just start to feed the relative motion events (if the information is available) to the SeatInterface together with the pointer events. On client side a new RelativePointerManager and RelativePointer class are added. The RelativePointerManager creates the RelativePointer for a given Pointer. The event sent to RelativePointer is transformed in a normal signal. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D2978
2016-10-07 07:07:34 +00:00
relativepointer_interface.cpp
relativepointer_interface_v1.cpp
[server] Introduce a base class Resource The Resource base class is supposed to be used by all interface classes which get created for a wl_resource. Most interface classes are adjusted, but there are some exceptions: * BufferInterface: is different as the wl_resource is already created * PointerInterface and KeyboardInterface: those two need changes, the implementation differs from all other interface implementations.
2014-11-14 08:45:02 +00:00
resource.cpp
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
seat_interface.cpp
Interface for a Slide effect a kwayland interface plus autotests for the slide KWin effect, marks a window the direction it wants to slide from and the offset from the screen edge
2015-09-09 11:04:11 +00:00
slide_interface.cpp
Add a Shadow protocol The shadow protocol is inspired by the KWin's X11 protocol and the DecorationShadow in KDecoration2. A shadow is attached to a surface (after a commit on surface) and consists of several image parts (represented through a buffer): * top-left * top * top-right * right * bottom-right * bottom * bottom-left * left In addition there is an offset on each side. For more information see also the X11 protocol described at [1]. Note: the protocol is currently missing documentation and changing the shadow is not yet properly delegated to the server API. [1] https://community.kde.org/KWin/Shadow
2015-07-15 09:07:50 +00:00
shadow_interface.cpp
Blur protocol in KWayland a protocol to activate the blur behind windows and to optionally set a sub region of the window where to apply the blur to, in case the window is shaped REVIEW:125015
2015-08-26 12:42:58 +00:00
blur_interface.cpp
Wayland protocol for background contrast new wayland protocol used to define regions behind a window in which the kwin background contrast effect should be applied REVIEW:125030
2015-09-02 16:13:25 +00:00
contrast_interface.cpp
[server] Add implementation for server side decoration protocol
2015-12-10 08:39:24 +00:00
server_decoration_interface.cpp
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
shell_interface.cpp
surface_interface.cpp
Add support for wl_subcompositor and wl_subsurface This implements the subcompositor and subsurface protocol on both Client and Server side. Client: New classes SubCompositor and SubSurface. The SubCompositor can be created through the Registry and creates the SubSurface which is bound to a Surface and has a parent Surface. The SubSurface class provides convenient wrappers for all calls exposed in the wl_subsurface interface. Server: New classes SubCompositorInterface and SubSurfaceInterface. Support for all commands is added, though the API probably still can need some fine tuning. The synchronized vs. desynchronized behavior is not yet exposed in the API. This could also be delegated towards the user of the library.
2014-10-14 12:04:35 +00:00
subcompositor_interface.cpp
[server] Add support for touch events in SeatInterface
2015-03-25 12:31:38 +00:00
touch_interface.cpp
Implement wl_text_input and zwp_text_input_v2 interfaces Summary: This change introduces support for text input. Text input allows to compose text on the server (e.g. through a virtual keyboard) and sent the composed text to the client. There are multiple interfaces for text input. QtWayland 5.6 uses wl_text_input, QtWayland 5.7 uses zwp_text_input_v2. wl_text_input is from pre Wayland-Protocols times and considered as UnstableV0 in this implementation. The other interface is UnstableV2. Unfortunately the V2 variant is not yet part of Wayland-Protocols, but used in Qt. The implementation hides the different interfaces as good as possible. The general idea is the same, the differences are rather minor. This means changes to how interfaces are wrapped normally. On client side in the Registry a manager is factored which represent either of the two interfaces. Similar on the server side Display's factory method takes an argument to decide which interface should be factored. This way a user of the library can expose both interfaces and thus be compatible with Qt 5.6 and Qt 5.7 onwards. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1631
2016-05-02 12:28:26 +00:00
textinput_interface.cpp
textinput_interface_v0.cpp
textinput_interface_v2.cpp
Add support for xdg-shell Summary: This change introduces support for the unstable xdg-shell interface in the server. The implementation is based on version 5 of the unstable interface. This is the version used by toolkits like e.g. GTK. There is also a version 6 of the protocol under development which is incompatible. This makes it difficult to implement it in a backward compatible way. Because of that the implementation is a little bit different to other interfaces and inspired by the TextInput interfaces: On client side an XdgShell class is exposed which does not represent it directly. Instead it delegates everything to an XdgShellUnstableV5 implementation. For the Surface/Popup the same is done. In the Registry it's possible to create an XdgShell and it accepts the XdgShellUnstableV5 and in future will accept XdgUnstableV6, etc. On server side it also follows the approach from TextInput. That is there is a version enum which gets passed to the factory method in Display. It currently supports only V5, but in future can be extended for V6. As there is lots of similar code between wl_shell, xdg_shell and in future xdg_shell_unstable_v6 a templated GenericShellInterface class is added which combines the common parts. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D2102
2016-04-21 10:56:02 +00:00
xdgshell_interface.cpp
xdgshell_v5_interface.cpp
Wayland foreign protocol Summary: Implement the "foreign" wayland protocol. A client can export a surface with an unique string as handle, then another client can refer to that surface and set an own surface as child of that surface. Potential use cases are out-of-process dialogs, such as file dialogs, meant to be used by sandboxed processes that may not have the access it needs to implement such dialogs. The handle needs to be shared between the processes with other means, such as dbus or command line paramenters. The public api of the server side only tracks parent/child relationships as this is the only data kwin would need it for, the rest of the api is not exported so should be safer from eventual protocol changes Test Plan: the autotest works, but has a lot of random crashes when deleting surfaces, unfortunately backtraces don't tell much and the crashes never occur when running into valgrind behavior may still be wrong, depending on how the protocol is supposed to work if more clients try to set the same exported surface as parent Reviewers: #plasma, #kwin, davidedmundson, graesslin Reviewed By: #plasma, #kwin, graesslin Subscribers: davidedmundson, graesslin, plasma-devel, #frameworks Tags: #frameworks, #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D7369
2017-10-13 09:29:17 +00:00
xdgforeign_v2_interface.cpp
xdgforeign_interface.cpp
Support XDG v6 Summary: The main clever part that's not just boring boiler plate is how we handle the structure change A surface now has an XDGSurface which then has a an Xdg TopLevel or a Xdg Popup We need to fit this into the public API which assumes a surface has a Surface or a Popup. The old Surface is similar to the new TopLevel. The shoehorning works by relying on the fact that a surface without a role is pretty useless. Clients create the surface implicitly with the toplevel or implicitly with the popup. The server only announced it has a new "XdgSurface" when it gets a new zxdg_surface_get_toplevel. ---- Popup decisions: - On popup creation the server should copy the current info from the positioner and then it gets deleted. Given kwaylands job is to keep state, we expose all these parameter via popup. - Due to this positioner is not exposed as a resource anywhere. - Server API is 100% backwards compatiable. i.e new code will work identically with v5 clients. - Client API is not. Grabs are called separately from the constructor, and the parent surface changed to an xdgsurface, not a raw surface. V5 code still works as-is, just not with the new constructors. It seemed better to match the v6 (and what will be the stable v7) than to try and do hacks and lose functionality. Given the client needs to change the code to opt into V6 anyway. I don't think this is a huge problem. Test Plan: Current test still passes. Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: graesslin, mart, plasma-devel, #frameworks Tags: #frameworks, #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D6047
2017-09-04 15:38:35 +00:00
xdgshell_v6_interface.cpp
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
)
server side of new outputmanagement protocol This implements the server part of the screen management protocol. The protocol is implemented as a wayland protocol. It provides the following mechanisms: - a list of outputs, close to wl_output, with additional properties for enabled, uuid, edid, etc.. These OutputDevices correspond to a connected output that can be enabled by the compositor, but is not necessarily currently used for rendering. - a global OutputManagement, which allows creating config objects, one per client. The client can make changes to the outputs through setScale(outputdevice*, scale) for example. - an OutputConfiguration resource, that can be handed to a client and used for configuration. Changes are double buffered here. Only after OutputConfiguration.apply() has been called, the changes are relayed over the global OutputManagement. The compositor is responsible to handle changes. For a more detailed description, see the API docs in especially outputconfiguration.h. REVIEW:125942
2015-11-04 14:36:52 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/output-management.xml
server side of new outputmanagement protocol This implements the server part of the screen management protocol. The protocol is implemented as a wayland protocol. It provides the following mechanisms: - a list of outputs, close to wl_output, with additional properties for enabled, uuid, edid, etc.. These OutputDevices correspond to a connected output that can be enabled by the compositor, but is not necessarily currently used for rendering. - a global OutputManagement, which allows creating config objects, one per client. The client can make changes to the outputs through setScale(outputdevice*, scale) for example. - an OutputConfiguration resource, that can be handed to a client and used for configuration. Changes are double buffered here. Only after OutputConfiguration.apply() has been called, the changes are relayed over the global OutputManagement. The compositor is responsible to handle changes. For a more detailed description, see the API docs in especially outputconfiguration.h. REVIEW:125942
2015-11-04 14:36:52 +00:00
BASENAME output-management
)
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/outputdevice.xml
server side of new outputmanagement protocol This implements the server part of the screen management protocol. The protocol is implemented as a wayland protocol. It provides the following mechanisms: - a list of outputs, close to wl_output, with additional properties for enabled, uuid, edid, etc.. These OutputDevices correspond to a connected output that can be enabled by the compositor, but is not necessarily currently used for rendering. - a global OutputManagement, which allows creating config objects, one per client. The client can make changes to the outputs through setScale(outputdevice*, scale) for example. - an OutputConfiguration resource, that can be handed to a client and used for configuration. Changes are double buffered here. Only after OutputConfiguration.apply() has been called, the changes are relayed over the global OutputManagement. The compositor is responsible to handle changes. For a more detailed description, see the API docs in especially outputconfiguration.h. REVIEW:125942
2015-11-04 14:36:52 +00:00
BASENAME org_kde_kwin_outputdevice
)
[server] Add bindings for PlasmaShell interface
2015-06-09 00:48:56 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/plasma-shell.xml
[server] Add bindings for PlasmaShell interface
2015-06-09 00:48:56 +00:00
BASENAME plasma-shell
)
[server] Add PlasmaWindowManagementInterface
2015-06-12 01:05:14 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/plasma-window-management.xml
[server] Add PlasmaWindowManagementInterface
2015-06-12 01:05:14 +00:00
BASENAME plasma-window-management
)
[server] Add support for QtSurfaceExtension protocol The Qt surface extension is a small protocol to allow exchanging additional data between QWindows and the compositor. What we are currently only interested in is the possibility to close a surface from the Compositor. Protocol description is copied from QtWayland 5.4.2 branch.
2015-06-09 22:56:31 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/surface-extension.xml
[server] Add support for QtSurfaceExtension protocol The Qt surface extension is a small protocol to allow exchanging additional data between QWindows and the compositor. What we are currently only interested in is the possibility to close a surface from the Compositor. Protocol description is copied from QtWayland 5.4.2 branch.
2015-06-09 22:56:31 +00:00
BASENAME qt-surface-extension
)
Add support for an idle time interface The idle time interface is modelled for the use cases of the KIdleTime framework to allow providing a Wayland specific implementation. It supports registering idle timeouts which are triggered on server side if there has not been any user activity on the seat for the requested amount of time. Once user activity resumes a resume from idle signal is emitted. In additon there is the possibility to simulate user activity which simulates the resume from idle.
2015-07-02 09:35:16 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/idle.xml
Add support for an idle time interface The idle time interface is modelled for the use cases of the KIdleTime framework to allow providing a Wayland specific implementation. It supports registering idle timeouts which are triggered on server side if there has not been any user activity on the seat for the requested amount of time. Once user activity resumes a resume from idle signal is emitted. In additon there is the possibility to simulate user activity which simulates the resume from idle.
2015-07-02 09:35:16 +00:00
BASENAME idle
)
Adding support for a fake input interface This interface allows a client to fake input events and the server might use them. There is an authentication mechanismn in place which requires the server to mark the client as authenticated in order for any events to be emitted at all. This interface is intended for use cases like kdeconnect which allows to remote control a device.
2015-07-02 19:21:57 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/fake-input.xml
Adding support for a fake input interface This interface allows a client to fake input events and the server might use them. There is an authentication mechanismn in place which requires the server to mark the client as authenticated in order for any events to be emitted at all. This interface is intended for use cases like kdeconnect which allows to remote control a device.
2015-07-02 19:21:57 +00:00
BASENAME fake-input
)
Add a Shadow protocol The shadow protocol is inspired by the KWin's X11 protocol and the DecorationShadow in KDecoration2. A shadow is attached to a surface (after a commit on surface) and consists of several image parts (represented through a buffer): * top-left * top * top-right * right * bottom-right * bottom * bottom-left * left In addition there is an offset on each side. For more information see also the X11 protocol described at [1]. Note: the protocol is currently missing documentation and changing the shadow is not yet properly delegated to the server API. [1] https://community.kde.org/KWin/Shadow
2015-07-15 09:07:50 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/shadow.xml
Add a Shadow protocol The shadow protocol is inspired by the KWin's X11 protocol and the DecorationShadow in KDecoration2. A shadow is attached to a surface (after a commit on surface) and consists of several image parts (represented through a buffer): * top-left * top * top-right * right * bottom-right * bottom * bottom-left * left In addition there is an offset on each side. For more information see also the X11 protocol described at [1]. Note: the protocol is currently missing documentation and changing the shadow is not yet properly delegated to the server API. [1] https://community.kde.org/KWin/Shadow
2015-07-15 09:07:50 +00:00
BASENAME shadow
)
[server] Add a DpmsManagerInterface 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.
2015-08-31 14:08:58 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/dpms.xml
[server] Add a DpmsManagerInterface 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.
2015-08-31 14:08:58 +00:00
BASENAME dpms
)
Add a Shadow protocol The shadow protocol is inspired by the KWin's X11 protocol and the DecorationShadow in KDecoration2. A shadow is attached to a surface (after a commit on surface) and consists of several image parts (represented through a buffer): * top-left * top * top-right * right * bottom-right * bottom * bottom-left * left In addition there is an offset on each side. For more information see also the X11 protocol described at [1]. Note: the protocol is currently missing documentation and changing the shadow is not yet properly delegated to the server API. [1] https://community.kde.org/KWin/Shadow
2015-07-15 09:07:50 +00:00
Blur protocol in KWayland a protocol to activate the blur behind windows and to optionally set a sub region of the window where to apply the blur to, in case the window is shaped REVIEW:125015
2015-08-26 12:42:58 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/blur.xml
Blur protocol in KWayland a protocol to activate the blur behind windows and to optionally set a sub region of the window where to apply the blur to, in case the window is shaped REVIEW:125015
2015-08-26 12:42:58 +00:00
BASENAME blur
)
Wayland protocol for background contrast new wayland protocol used to define regions behind a window in which the kwin background contrast effect should be applied REVIEW:125030
2015-09-02 16:13:25 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/contrast.xml
Wayland protocol for background contrast new wayland protocol used to define regions behind a window in which the kwin background contrast effect should be applied REVIEW:125030
2015-09-02 16:13:25 +00:00
BASENAME contrast
)
Implement support for the relative pointer protocol Summary: This change implements the zwp_relative_pointer_v1 protocol which allows to send relative motion events. The (unstable) protocol consists of a RelativePointerManager which creates RelativePointers for a given Pointer. This interface currently only has one event to report the relative motion. It carries the delta, the non-accelerated-delta and a timestamp in microsends granularity. On the server side the implementation is mostly internal. Once a RelativePointerManagerInterface is created one can send relative motion events through the SeatInterface. The SeatInterface takes care of sending it to the responding RelativePointerInterface. The protocol does not restrict the sending of "normal" and relative motion events. Thus it can be combined in any way one wants. This allows to have a rather simple implementation. A user of the SeatInterface can just start to feed the relative motion events (if the information is available) to the SeatInterface together with the pointer events. On client side a new RelativePointerManager and RelativePointer class are added. The RelativePointerManager creates the RelativePointer for a given Pointer. The event sent to RelativePointer is transformed in a normal signal. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D2978
2016-10-07 07:07:34 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/relative-pointer-unstable-v1.xml
Implement support for the relative pointer protocol Summary: This change implements the zwp_relative_pointer_v1 protocol which allows to send relative motion events. The (unstable) protocol consists of a RelativePointerManager which creates RelativePointers for a given Pointer. This interface currently only has one event to report the relative motion. It carries the delta, the non-accelerated-delta and a timestamp in microsends granularity. On the server side the implementation is mostly internal. Once a RelativePointerManagerInterface is created one can send relative motion events through the SeatInterface. The SeatInterface takes care of sending it to the responding RelativePointerInterface. The protocol does not restrict the sending of "normal" and relative motion events. Thus it can be combined in any way one wants. This allows to have a rather simple implementation. A user of the SeatInterface can just start to feed the relative motion events (if the information is available) to the SeatInterface together with the pointer events. On client side a new RelativePointerManager and RelativePointer class are added. The RelativePointerManager creates the RelativePointer for a given Pointer. The event sent to RelativePointer is transformed in a normal signal. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D2978
2016-10-07 07:07:34 +00:00
BASENAME relativepointer-unstable-v1
)
Interface for a Slide effect a kwayland interface plus autotests for the slide KWin effect, marks a window the direction it wants to slide from and the offset from the screen edge
2015-09-09 11:04:11 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/slide.xml
Interface for a Slide effect a kwayland interface plus autotests for the slide KWin effect, marks a window the direction it wants to slide from and the offset from the screen edge
2015-09-09 11:04:11 +00:00
BASENAME slide
)
[server] Add implementation for server side decoration protocol
2015-12-10 08:39:24 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/server-decoration.xml
[server] Add implementation for server side decoration protocol
2015-12-10 08:39:24 +00:00
BASENAME server_decoration
)
Implement wl_text_input and zwp_text_input_v2 interfaces Summary: This change introduces support for text input. Text input allows to compose text on the server (e.g. through a virtual keyboard) and sent the composed text to the client. There are multiple interfaces for text input. QtWayland 5.6 uses wl_text_input, QtWayland 5.7 uses zwp_text_input_v2. wl_text_input is from pre Wayland-Protocols times and considered as UnstableV0 in this implementation. The other interface is UnstableV2. Unfortunately the V2 variant is not yet part of Wayland-Protocols, but used in Qt. The implementation hides the different interfaces as good as possible. The general idea is the same, the differences are rather minor. This means changes to how interfaces are wrapped normally. On client side in the Registry a manager is factored which represent either of the two interfaces. Similar on the server side Display's factory method takes an argument to decide which interface should be factored. This way a user of the library can expose both interfaces and thus be compatible with Qt 5.6 and Qt 5.7 onwards. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1631
2016-05-02 12:28:26 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/text-input.xml
Implement wl_text_input and zwp_text_input_v2 interfaces Summary: This change introduces support for text input. Text input allows to compose text on the server (e.g. through a virtual keyboard) and sent the composed text to the client. There are multiple interfaces for text input. QtWayland 5.6 uses wl_text_input, QtWayland 5.7 uses zwp_text_input_v2. wl_text_input is from pre Wayland-Protocols times and considered as UnstableV0 in this implementation. The other interface is UnstableV2. Unfortunately the V2 variant is not yet part of Wayland-Protocols, but used in Qt. The implementation hides the different interfaces as good as possible. The general idea is the same, the differences are rather minor. This means changes to how interfaces are wrapped normally. On client side in the Registry a manager is factored which represent either of the two interfaces. Similar on the server side Display's factory method takes an argument to decide which interface should be factored. This way a user of the library can expose both interfaces and thus be compatible with Qt 5.6 and Qt 5.7 onwards. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1631
2016-05-02 12:28:26 +00:00
BASENAME text
)
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/text-input-unstable-v2.xml
Implement wl_text_input and zwp_text_input_v2 interfaces Summary: This change introduces support for text input. Text input allows to compose text on the server (e.g. through a virtual keyboard) and sent the composed text to the client. There are multiple interfaces for text input. QtWayland 5.6 uses wl_text_input, QtWayland 5.7 uses zwp_text_input_v2. wl_text_input is from pre Wayland-Protocols times and considered as UnstableV0 in this implementation. The other interface is UnstableV2. Unfortunately the V2 variant is not yet part of Wayland-Protocols, but used in Qt. The implementation hides the different interfaces as good as possible. The general idea is the same, the differences are rather minor. This means changes to how interfaces are wrapped normally. On client side in the Registry a manager is factored which represent either of the two interfaces. Similar on the server side Display's factory method takes an argument to decide which interface should be factored. This way a user of the library can expose both interfaces and thus be compatible with Qt 5.6 and Qt 5.7 onwards. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1631
2016-05-02 12:28:26 +00:00
BASENAME text-input-unstable-v2
)
Add support for xdg-shell Summary: This change introduces support for the unstable xdg-shell interface in the server. The implementation is based on version 5 of the unstable interface. This is the version used by toolkits like e.g. GTK. There is also a version 6 of the protocol under development which is incompatible. This makes it difficult to implement it in a backward compatible way. Because of that the implementation is a little bit different to other interfaces and inspired by the TextInput interfaces: On client side an XdgShell class is exposed which does not represent it directly. Instead it delegates everything to an XdgShellUnstableV5 implementation. For the Surface/Popup the same is done. In the Registry it's possible to create an XdgShell and it accepts the XdgShellUnstableV5 and in future will accept XdgUnstableV6, etc. On server side it also follows the approach from TextInput. That is there is a version enum which gets passed to the factory method in Display. It currently supports only V5, but in future can be extended for V6. As there is lots of similar code between wl_shell, xdg_shell and in future xdg_shell_unstable_v6 a templated GenericShellInterface class is added which combines the common parts. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D2102
2016-04-21 10:56:02 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Unbreak build: adapt cmake var names to KWAYLAND->KWayland change project() sets more variables than I remembered Fix-up for f90f647227508943ec8f919285fd16f0440261b9
2016-11-03 15:46:37 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/xdg-shell-unstable-v5.xml
Add support for xdg-shell Summary: This change introduces support for the unstable xdg-shell interface in the server. The implementation is based on version 5 of the unstable interface. This is the version used by toolkits like e.g. GTK. There is also a version 6 of the protocol under development which is incompatible. This makes it difficult to implement it in a backward compatible way. Because of that the implementation is a little bit different to other interfaces and inspired by the TextInput interfaces: On client side an XdgShell class is exposed which does not represent it directly. Instead it delegates everything to an XdgShellUnstableV5 implementation. For the Surface/Popup the same is done. In the Registry it's possible to create an XdgShell and it accepts the XdgShellUnstableV5 and in future will accept XdgUnstableV6, etc. On server side it also follows the approach from TextInput. That is there is a version enum which gets passed to the factory method in Display. It currently supports only V5, but in future can be extended for V6. As there is lots of similar code between wl_shell, xdg_shell and in future xdg_shell_unstable_v6 a templated GenericShellInterface class is added which combines the common parts. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D2102
2016-04-21 10:56:02 +00:00
BASENAME xdg-shell-v5
)
Support XDG v6 Summary: The main clever part that's not just boring boiler plate is how we handle the structure change A surface now has an XDGSurface which then has a an Xdg TopLevel or a Xdg Popup We need to fit this into the public API which assumes a surface has a Surface or a Popup. The old Surface is similar to the new TopLevel. The shoehorning works by relying on the fact that a surface without a role is pretty useless. Clients create the surface implicitly with the toplevel or implicitly with the popup. The server only announced it has a new "XdgSurface" when it gets a new zxdg_surface_get_toplevel. ---- Popup decisions: - On popup creation the server should copy the current info from the positioner and then it gets deleted. Given kwaylands job is to keep state, we expose all these parameter via popup. - Due to this positioner is not exposed as a resource anywhere. - Server API is 100% backwards compatiable. i.e new code will work identically with v5 clients. - Client API is not. Grabs are called separately from the constructor, and the parent surface changed to an xdgsurface, not a raw surface. V5 code still works as-is, just not with the new constructors. It seemed better to match the v6 (and what will be the stable v7) than to try and do hacks and lose functionality. Given the client needs to change the code to opt into V6 anyway. I don't think this is a huge problem. Test Plan: Current test still passes. Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: graesslin, mart, plasma-devel, #frameworks Tags: #frameworks, #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D6047
2017-09-04 15:38:35 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/xdg-shell-unstable-v6.xml
BASENAME xdg-shell-v6
)
Implementation of PointerGestures protocol Summary: Pointer gestures are created for a pointer and there are two types of gestures: swipe and pinch. At a given time there can only be one active gesture. The implementation in SeatInterface ensures that there can only be one active gesture. Each gesture consists of a start event, 0 to multiple update events and an end event. The end can also be a cancel. To better support this the implementation doesn't follow the protocol and splits end and cancel into dedicated methods in the server side and into dedicated signals in the client side. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D3169
2016-10-26 08:27:14 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
Fix build - KWayland_SOURCE_DIR instead of KWAYLAND_SOURCE_DIR Change was prepared prior to project name change. Sorry about breaking.
2016-11-07 12:34:08 +00:00
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/pointer-gestures-unstable-v1.xml
Implementation of PointerGestures protocol Summary: Pointer gestures are created for a pointer and there are two types of gestures: swipe and pinch. At a given time there can only be one active gesture. The implementation in SeatInterface ensures that there can only be one active gesture. Each gesture consists of a start event, 0 to multiple update events and an end event. The end can also be a cancel. To better support this the implementation doesn't follow the protocol and splits end and cancel into dedicated methods in the server side and into dedicated signals in the client side. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D3169
2016-10-26 08:27:14 +00:00
BASENAME pointer-gestures-unstable-v1
)
Implementation of PointerConstraints protcol Summary: The pointer constraints protocol is an unstable protocol and thus the implementation follows the semantics of unstable protocols. The protocol allows to create a constraint on the pointer - either a lock or a confinement on a surface. Those are not activated at once, but when the compositor actively grants it. During lock no further pointer motion is emitted, during confinement the pointer is kept in a certain area. This implements T4451. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D3466
2016-11-08 13:17:15 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/pointer-constraints-unstable-v1.xml
BASENAME pointer-constraints-unstable-v1
)
Wayland foreign protocol Summary: Implement the "foreign" wayland protocol. A client can export a surface with an unique string as handle, then another client can refer to that surface and set an own surface as child of that surface. Potential use cases are out-of-process dialogs, such as file dialogs, meant to be used by sandboxed processes that may not have the access it needs to implement such dialogs. The handle needs to be shared between the processes with other means, such as dbus or command line paramenters. The public api of the server side only tracks parent/child relationships as this is the only data kwin would need it for, the rest of the api is not exported so should be safer from eventual protocol changes Test Plan: the autotest works, but has a lot of random crashes when deleting surfaces, unfortunately backtraces don't tell much and the crashes never occur when running into valgrind behavior may still be wrong, depending on how the protocol is supposed to work if more clients try to set the same exported surface as parent Reviewers: #plasma, #kwin, davidedmundson, graesslin Reviewed By: #plasma, #kwin, graesslin Subscribers: davidedmundson, graesslin, plasma-devel, #frameworks Tags: #frameworks, #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D7369
2017-10-13 09:29:17 +00:00
ecm_add_wayland_server_protocol(SERVER_LIB_SRCS
PROTOCOL ${KWayland_SOURCE_DIR}/src/client/protocols/xdg-foreign-unstable-v2.xml
BASENAME xdg-foreign-unstable-v2
)
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
add_library(KF5WaylandServer ${SERVER_LIB_SRCS})
Fix export header for WaylandServer This makes it possible to install and then use it. Installation is still commented since we can't give enough stability guarantees for now. In detail: - do not actually install headers - generate the export header into Wayland/Server - include it from there REVIEW:120579
2014-10-14 11:43:24 +00:00
generate_export_header(KF5WaylandServer
BASE_NAME
KWaylandServer
EXPORT_FILE_NAME
KWayland/Server/kwaylandserver_export.h
)
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
add_library(KF5::WaylandServer ALIAS KF5WaylandServer)
Install library and headers
2014-09-17 13:47:42 +00:00
target_include_directories(KF5WaylandServer INTERFACE "$<INSTALL_INTERFACE:${KF5_INCLUDE_INSTALL_DIR}/KWayland/Server>")
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
target_link_libraries(KF5WaylandServer
PUBLIC Qt5::Gui
[server] BufferInterface can resolve size through egl extension Uses eglQueryWaylandBufferWL (if available) to determine the size of the buffer. In order to do so, the server library links against egl (1) and one needs to register the EGLDisplay in Server::Display by the user of the library. For this a new method Display::setEglDisplay is added. 1: not using epoxy as it doesn't wrap the Wayland interfaces yet.
2015-03-03 08:43:30 +00:00
PRIVATE
Wayland::Server
EGL::EGL
Support passing generic QIcon through PlasmaWindow interface Summary: Especially for Xwayland windows the compositor might not have a themed icon name. Resulting in a task manager not having dedicated icons for Xwayland windows. This change deprecates the way how a compositor is supposed to set the window icon. Instead of passing the themed icon name, it is now supposed to pass the QIcon. In case it's a themed icon the existing way to pass to the client is used. Otherwise a new event is used to inform the client that there is an icon - no data is transmitted at this point. The client can then create a file descriptor and pass it to the compositor. The compositor serializes the icon into the file descriptor and the client can read from it. This all happens transparently on client side there is no api change at all. The writing and reading of the icon is done in a thread. Due to that Qt5::Concurrent is now a required dependency instead of an optional dependency. Reviewers: #plasma_on_wayland, hein Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D3049
2016-10-13 11:39:27 +00:00
Qt5::Concurrent
Add a build system Framework style build system which generates two libraries: * KF5WaylandClient * KF5WaylandServer autotests are adjusted to compile again. They need to be changed to use the libraries once the export header gets generated.
2014-09-17 12:35:33 +00:00
)
Install library and headers
2014-09-17 13:47:42 +00:00
set_target_properties(KF5WaylandServer PROPERTIES VERSION ${KWAYLAND_VERSION_STRING}
SOVERSION ${KWAYLAND_SOVERSION}
EXPORT_NAME WaylandServer
)
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
install(TARGETS KF5WaylandServer EXPORT KF5WaylandTargets ${KF5_INSTALL_TARGETS_DEFAULT_ARGS})
[FEATURE] Option to build & install QCH file with the public API dox Using the new extra-cmake-modules module ECMAddQch (since 5.36.0) this adds the option to automatically build and install a file in QCH format with the docs about the public API, which then can be used e.g. in Qt Assistant, Qt Creator or KDevelop. Additionally the installed cmake config files will be extended with a target KF5Wayland_QCH containing information about how to "link" into the generated QCH file, which then can be used in the cmake build system of other libraries building on this library, by simply listing this target in "LINK_QCHS" of their ecm_add_qch() usage. And a respective doxygen tag file with all the metadata about the generated QCH file and used for the "linking" will be created and installed. Pass -DBUILD_QCH=ON to cmake to enable this.
2017-05-26 00:36:23 +00:00
set(SERVER_LIB_HEADERS
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
${CMAKE_CURRENT_BINARY_DIR}/KWayland/Server/kwaylandserver_export.h
Blur protocol in KWayland a protocol to activate the blur behind windows and to optionally set a sub region of the window where to apply the blur to, in case the window is shaped REVIEW:125015
2015-08-26 12:42:58 +00:00
blur_interface.h
Wayland protocol for background contrast new wayland protocol used to define regions behind a window in which the kwin background contrast effect should be applied REVIEW:125030
2015-09-02 16:13:25 +00:00
contrast_interface.h
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
buffer_interface.h
clientconnection.h
compositor_interface.h
datadevice_interface.h
datadevicemanager_interface.h
dataoffer_interface.h
datasource_interface.h
display.h
[server] Add a DpmsManagerInterface 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.
2015-08-31 14:08:58 +00:00
dpms_interface.h
Adding support for a fake input interface This interface allows a client to fake input events and the server might use them. There is an authentication mechanismn in place which requires the server to mark the client as authenticated in order for any events to be emitted at all. This interface is intended for use cases like kdeconnect which allows to remote control a device.
2015-07-02 19:21:57 +00:00
fakeinput_interface.h
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
global.h
Add support for an idle time interface The idle time interface is modelled for the use cases of the KIdleTime framework to allow providing a Wayland specific implementation. It supports registering idle timeouts which are triggered on server side if there has not been any user activity on the seat for the requested amount of time. Once user activity resumes a resume from idle signal is emitted. In additon there is the possibility to simulate user activity which simulates the resume from idle.
2015-07-02 09:35:16 +00:00
idle_interface.h
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
keyboard_interface.h
server side of new outputmanagement protocol This implements the server part of the screen management protocol. The protocol is implemented as a wayland protocol. It provides the following mechanisms: - a list of outputs, close to wl_output, with additional properties for enabled, uuid, edid, etc.. These OutputDevices correspond to a connected output that can be enabled by the compositor, but is not necessarily currently used for rendering. - a global OutputManagement, which allows creating config objects, one per client. The client can make changes to the outputs through setScale(outputdevice*, scale) for example. - an OutputConfiguration resource, that can be handed to a client and used for configuration. Changes are double buffered here. Only after OutputConfiguration.apply() has been called, the changes are relayed over the global OutputManagement. The compositor is responsible to handle changes. For a more detailed description, see the API docs in especially outputconfiguration.h. REVIEW:125942
2015-11-04 14:36:52 +00:00
outputdevice_interface.h
outputchangeset.h
outputconfiguration_interface.h
outputmanagement_interface.h
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
output_interface.h
pointer_interface.h
Implementation of PointerConstraints protcol Summary: The pointer constraints protocol is an unstable protocol and thus the implementation follows the semantics of unstable protocols. The protocol allows to create a constraint on the pointer - either a lock or a confinement on a surface. Those are not activated at once, but when the compositor actively grants it. During lock no further pointer motion is emitted, during confinement the pointer is kept in a certain area. This implements T4451. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D3466
2016-11-08 13:17:15 +00:00
pointerconstraints_interface.h
Implementation of PointerGestures protocol Summary: Pointer gestures are created for a pointer and there are two types of gestures: swipe and pinch. At a given time there can only be one active gesture. The implementation in SeatInterface ensures that there can only be one active gesture. Each gesture consists of a start event, 0 to multiple update events and an end event. The end can also be a cancel. To better support this the implementation doesn't follow the protocol and splits end and cancel into dedicated methods in the server side and into dedicated signals in the client side. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D3169
2016-10-26 08:27:14 +00:00
pointergestures_interface.h
[server] Add bindings for PlasmaShell interface
2015-06-09 00:48:56 +00:00
plasmashell_interface.h
[server] Add PlasmaWindowManagementInterface
2015-06-12 01:05:14 +00:00
plasmawindowmanagement_interface.h
[server] Add support for QtSurfaceExtension protocol The Qt surface extension is a small protocol to allow exchanging additional data between QWindows and the compositor. What we are currently only interested in is the possibility to close a surface from the Compositor. Protocol description is copied from QtWayland 5.4.2 branch.
2015-06-09 22:56:31 +00:00
qtsurfaceextension_interface.h
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
region_interface.h
Implement support for the relative pointer protocol Summary: This change implements the zwp_relative_pointer_v1 protocol which allows to send relative motion events. The (unstable) protocol consists of a RelativePointerManager which creates RelativePointers for a given Pointer. This interface currently only has one event to report the relative motion. It carries the delta, the non-accelerated-delta and a timestamp in microsends granularity. On the server side the implementation is mostly internal. Once a RelativePointerManagerInterface is created one can send relative motion events through the SeatInterface. The SeatInterface takes care of sending it to the responding RelativePointerInterface. The protocol does not restrict the sending of "normal" and relative motion events. Thus it can be combined in any way one wants. This allows to have a rather simple implementation. A user of the SeatInterface can just start to feed the relative motion events (if the information is available) to the SeatInterface together with the pointer events. On client side a new RelativePointerManager and RelativePointer class are added. The RelativePointerManager creates the RelativePointer for a given Pointer. The event sent to RelativePointer is transformed in a normal signal. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D2978
2016-10-07 07:07:34 +00:00
relativepointer_interface.h
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
resource.h
seat_interface.h
[server] Add implementation for server side decoration protocol
2015-12-10 08:39:24 +00:00
server_decoration_interface.h
Add a Shadow protocol The shadow protocol is inspired by the KWin's X11 protocol and the DecorationShadow in KDecoration2. A shadow is attached to a surface (after a commit on surface) and consists of several image parts (represented through a buffer): * top-left * top * top-right * right * bottom-right * bottom * bottom-left * left In addition there is an offset on each side. For more information see also the X11 protocol described at [1]. Note: the protocol is currently missing documentation and changing the shadow is not yet properly delegated to the server API. [1] https://community.kde.org/KWin/Shadow
2015-07-15 09:07:50 +00:00
shadow_interface.h
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
shell_interface.h
[server] Install slide_interface.h CCMAIL: notmart@gmail.com
2015-09-10 06:19:39 +00:00
slide_interface.h
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
subcompositor_interface.h
surface_interface.h
Implement wl_text_input and zwp_text_input_v2 interfaces Summary: This change introduces support for text input. Text input allows to compose text on the server (e.g. through a virtual keyboard) and sent the composed text to the client. There are multiple interfaces for text input. QtWayland 5.6 uses wl_text_input, QtWayland 5.7 uses zwp_text_input_v2. wl_text_input is from pre Wayland-Protocols times and considered as UnstableV0 in this implementation. The other interface is UnstableV2. Unfortunately the V2 variant is not yet part of Wayland-Protocols, but used in Qt. The implementation hides the different interfaces as good as possible. The general idea is the same, the differences are rather minor. This means changes to how interfaces are wrapped normally. On client side in the Registry a manager is factored which represent either of the two interfaces. Similar on the server side Display's factory method takes an argument to decide which interface should be factored. This way a user of the library can expose both interfaces and thus be compatible with Qt 5.6 and Qt 5.7 onwards. Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D1631
2016-05-02 12:28:26 +00:00
textinput_interface.h
Install new headers
2015-03-25 13:23:08 +00:00
touch_interface.h
Add support for xdg-shell Summary: This change introduces support for the unstable xdg-shell interface in the server. The implementation is based on version 5 of the unstable interface. This is the version used by toolkits like e.g. GTK. There is also a version 6 of the protocol under development which is incompatible. This makes it difficult to implement it in a backward compatible way. Because of that the implementation is a little bit different to other interfaces and inspired by the TextInput interfaces: On client side an XdgShell class is exposed which does not represent it directly. Instead it delegates everything to an XdgShellUnstableV5 implementation. For the Surface/Popup the same is done. In the Registry it's possible to create an XdgShell and it accepts the XdgShellUnstableV5 and in future will accept XdgUnstableV6, etc. On server side it also follows the approach from TextInput. That is there is a version enum which gets passed to the factory method in Display. It currently supports only V5, but in future can be extended for V6. As there is lots of similar code between wl_shell, xdg_shell and in future xdg_shell_unstable_v6 a templated GenericShellInterface class is added which combines the common parts. Reviewers: #plasma_on_wayland Subscribers: plasma-devel Tags: #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D2102
2016-04-21 10:56:02 +00:00
xdgshell_interface.h
Wayland foreign protocol Summary: Implement the "foreign" wayland protocol. A client can export a surface with an unique string as handle, then another client can refer to that surface and set an own surface as child of that surface. Potential use cases are out-of-process dialogs, such as file dialogs, meant to be used by sandboxed processes that may not have the access it needs to implement such dialogs. The handle needs to be shared between the processes with other means, such as dbus or command line paramenters. The public api of the server side only tracks parent/child relationships as this is the only data kwin would need it for, the rest of the api is not exported so should be safer from eventual protocol changes Test Plan: the autotest works, but has a lot of random crashes when deleting surfaces, unfortunately backtraces don't tell much and the crashes never occur when running into valgrind behavior may still be wrong, depending on how the protocol is supposed to work if more clients try to set the same exported surface as parent Reviewers: #plasma, #kwin, davidedmundson, graesslin Reviewed By: #plasma, #kwin, graesslin Subscribers: davidedmundson, graesslin, plasma-devel, #frameworks Tags: #frameworks, #plasma_on_wayland Differential Revision: https://phabricator.kde.org/D7369
2017-10-13 09:29:17 +00:00
xdgforeign_interface.h
[FEATURE] Option to build & install QCH file with the public API dox Using the new extra-cmake-modules module ECMAddQch (since 5.36.0) this adds the option to automatically build and install a file in QCH format with the docs about the public API, which then can be used e.g. in Qt Assistant, Qt Creator or KDevelop. Additionally the installed cmake config files will be extended with a target KF5Wayland_QCH containing information about how to "link" into the generated QCH file, which then can be used in the cmake build system of other libraries building on this library, by simply listing this target in "LINK_QCHS" of their ecm_add_qch() usage. And a respective doxygen tag file with all the metadata about the generated QCH file and used for the "linking" will be created and installed. Pass -DBUILD_QCH=ON to cmake to enable this.
2017-05-26 00:36:23 +00:00
)
install(FILES
${SERVER_LIB_HEADERS}
Install KF5WaylandServer and headers CCMAIL: sebas@kde.org
2014-11-27 17:26:33 +00:00
DESTINATION ${KF5_INCLUDE_INSTALL_DIR}/KWayland/Server COMPONENT Devel
)
make KWayland usable from qmake
2015-06-18 00:05:05 +00:00
[FEATURE] Option to build & install QCH file with the public API dox Using the new extra-cmake-modules module ECMAddQch (since 5.36.0) this adds the option to automatically build and install a file in QCH format with the docs about the public API, which then can be used e.g. in Qt Assistant, Qt Creator or KDevelop. Additionally the installed cmake config files will be extended with a target KF5Wayland_QCH containing information about how to "link" into the generated QCH file, which then can be used in the cmake build system of other libraries building on this library, by simply listing this target in "LINK_QCHS" of their ecm_add_qch() usage. And a respective doxygen tag file with all the metadata about the generated QCH file and used for the "linking" will be created and installed. Pass -DBUILD_QCH=ON to cmake to enable this.
2017-05-26 00:36:23 +00:00
# make available to ecm_add_qch in parent folder
set(KWaylandServer_APIDOX_SRCS ${SERVER_LIB_HEADERS} PARENT_SCOPE)
make KWayland usable from qmake
2015-06-18 00:05:05 +00:00
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KWaylandServer LIB_NAME KF5WaylandServer DEPS "core" FILENAME_VAR PRI_FILENAME INCLUDE_INSTALL_DIR ${KDE_INSTALL_INCLUDEDIR_KF5})
install(FILES ${PRI_FILENAME}
DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
Reference in a new issue Copy permalink