There can only be one focused surface per Seat, thus the information
should be hold in the seat.
This only adjusts the API, the actual data is still hold in the
PointerInterface. This still needs adjustment.
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.
Required information is passed through the ctor of Private.
::create is still virtual as ShellSurfaceInterface is retrieving
client information. This can be fixed once we have a better wl_client
encapsulation class.
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.
Version and interface get passed to the ctor allowing Global::Private
to implement ::create instead of providing a pure virtual method.
Also the static bind method is added to the Global::Private which
delegates into a pure virtual method.
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.
The BufferInterface used nested calls of wl_shm_buffer_begin_access
and allowed multiple different BufferInterfaces to be in a block
between wl_shm_buffer_begin_access and wl_shm_buffer_end_access.
But this is not allowed: nesting is only possible if it accesses
the same buffer!
This resulted in an abort when we accessed two BufferInterfaces
at the same time. The added test case aborts in the previous
version.
The fix now changes the semantic of the method. The BufferInterface
doesn't hold the QImage any more, but creates a new one every time
::data is invoked. The QImage is created with a custom cleanup
function which calls to wl_shm_buffer_end_access. It ensures that
we don't call into wl_shm_buffer_begin_access as long as there is
a valid QImage for any other BufferInterface still around and
instead returns a null QImage.
Thus a user of a BufferInterface::data should destroy the returned
QImage as soon as it's no longer needed or create a deep copy if
it needs to be kept around.
Counter part for the copyClient test app: the pasteClient test app
creates and maps a shell surface and waits for selection announce,
initiates the copy/paste mechanismn and prints out what got pasted.
After success it closes itself.
The test application copyClient creates a ShellSurface, maps it as
fullscreen, renders a green buffer and when it gets pointer focus it
sets "foo" in mimetype "text/plain" into the selection.
This test application "testRenderingServer" is able to start a
Wayland server and uses a QWidget to render the "scene". It manages
ShellSurfaces and renders them on the QWidget in a very static way.
Furthermore input events (key, pointer, wheel) are forwarded to the
top most Surface.
This test server is able to support kwin_wayland as a client, but
weston's test application in latest release fail due to missing
xdg_shell support.
Qt::MouseButton is mapped to the linux buttons. The mapping does
not match the mapping used in QtWayland module [1] as that seems
to be incorrect to me. E.g. Qt::BackButton is not mapped to BTN_BACK.
[1] qtwayland/src/client/qwaylandinputdevice.cpp
Proof-of-concept code illustrating how to start a Wayland server
before creating the QGuiApplication and also starting an Xwayland
server before creating the QGuiApplication. Thus the QGuiApplication
is able to connect to the Xwayland server started in the same
application.
Event dispatching in Display requires a QSocketNotifier which
requires the QCoreApplication to be created. This requirement renders
it impossible to create the server before the QCoreApplication is
created. But there are use cases which need this:
Let's assume we want to integrate a wayland server into an existing
X11 dependent application which uses QApplication and enforces the
xcb plugin. This means said application requires that an X Server is
up and running before the QApplication is created. If we want said
application to connect to an Xwayland server we need to be able to
create the Wayland server AND the Xwayland server before creating
the QApplication.
The solution is to only create the socket notifier if the
QCoreApplication exists. For the case that it doesn't exist an
additional method is added which needs to be called once the
QCoreApplication got created. In addition a manual event dispatch
method is added which allows to block for events when we don't
have a QSocketNotifier set up yet.
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.
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.
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
Emitted when the Wayland display is done flushing the initial interface
callbacks, announcing wl_display properties. This can be used to compress
events. Note that this signal is emitted only after announcing interfaces,
such as outputs, but not after receiving callbacks of interface properties,
such as the output's geometry, modes, etc..
This signal is emitted from the wl_display_sync callback.
REVIEW:120471
The test started to fail on my system without changing anything. I
assume my system got an update to latest wayland version and it
looks like the registry doesn't announce anything if nothing is
registered. So now our display at least creates the Shm interface.
In addition the test case is slightly improved with a few smaller
changes added during the debug session.
