kwin/src/inputpanelv1window.h

102 lines
2 KiB
C
Raw Normal View History

2020-07-11 16:40:28 +00:00
/*
KWin - the KDE window manager
This file is part of the KDE project.
SPDX-FileCopyrightText: 2020 Aleix Pol Gonzalez <aleixpol@kde.org>
SPDX-License-Identifier: GPL-2.0-or-later
*/
#pragma once
#include "wayland/inputmethod_v1.h"
#include "waylandwindow.h"
#include <QPointer>
2020-07-11 16:40:28 +00:00
namespace KWin
{
class Output;
2020-07-11 16:40:28 +00:00
class InputPanelV1Window : public WaylandWindow
2020-07-11 16:40:28 +00:00
{
Q_OBJECT
public:
InputPanelV1Window(InputPanelSurfaceV1Interface *panelSurface);
2020-07-11 16:40:28 +00:00
enum class Mode {
None,
VirtualKeyboard,
2020-07-11 16:40:28 +00:00
Overlay,
};
Q_ENUM(Mode)
void destroyWindow() override;
bool isPlaceable() const override
{
return false;
}
bool isCloseable() const override
{
return false;
}
bool isResizable() const override
{
return false;
}
bool isMovable() const override
{
return false;
}
bool isMovableAcrossScreens() const override
{
return false;
}
bool acceptsFocus() const override
{
return false;
}
void closeWindow() override
{
}
bool takeFocus() override
{
return false;
}
bool wantsInput() const override
{
return false;
}
bool isInputMethod() const override
{
return true;
}
NET::WindowType windowType(bool direct = false) const override;
QRectF frameRectToBufferRect(const QRectF &rect) const override;
2020-07-11 16:40:28 +00:00
Mode mode() const
{
return m_mode;
}
void allow();
void show();
void hide();
Rework async geometry updates Window management features were written with synchronous geometry updates in mind. Currently, this poses a big problem on Wayland because geometry updates are done in asynchronous fashion there. At the moment, geometry is updated in a so called pseudo-asynchronous fashion, meaning that the frame geometry will be reset to the old value once geometry updates are unblocked. The main drawback of this approach is that it is too error prone, the data flow is hard to comprehend, etc. It is worth noting that there is already a machinery to perform async geometry which is used during interactive move/resize operations. This change extends the move/resize geometry usage beyond interactive move/resize to make asynchronous geometry updates less error prone and easier to comprehend. With the proposed solution, all geometry updates must be done on the move/resize geometry first. After that, the new geometry is passed on to the Client-specific implementation of moveResizeInternal(). To be more specific, the frameGeometry() returns the current frame geometry, it is primarily useful only to the scene. If you want to move or resize a window, you need to use moveResizeGeometry() because it corresponds to the last requested frame geometry. It is worth noting that the moveResizeGeometry() returns the desired bounding geometry. The client may commit the xdg_toplevel surface with a slightly smaller window geometry, for example to enforce a specific aspect ratio. The client is not allowed to resize beyond the size as indicated in moveResizeGeometry(). The data flow is very simple: moveResize() updates the move/resize geometry and calls the client-specific implementation of the moveResizeInternal() method. Based on whether a configure event is needed, moveResizeInternal() will update the frameGeometry() either immediately or after the client commits a new buffer. Unfortunately, both the compositor and xdg-shell clients try to update the window geometry. It means that it's possible to have conflicts between the two. With this change, the compositor's move resize geometry will be synced only if there are no pending configure events, meaning that the user doesn't try to resize the window.
2021-04-30 18:26:09 +00:00
protected:
void moveResizeInternal(const QRectF &rect, MoveResizeMode mode) override;
Rework async geometry updates Window management features were written with synchronous geometry updates in mind. Currently, this poses a big problem on Wayland because geometry updates are done in asynchronous fashion there. At the moment, geometry is updated in a so called pseudo-asynchronous fashion, meaning that the frame geometry will be reset to the old value once geometry updates are unblocked. The main drawback of this approach is that it is too error prone, the data flow is hard to comprehend, etc. It is worth noting that there is already a machinery to perform async geometry which is used during interactive move/resize operations. This change extends the move/resize geometry usage beyond interactive move/resize to make asynchronous geometry updates less error prone and easier to comprehend. With the proposed solution, all geometry updates must be done on the move/resize geometry first. After that, the new geometry is passed on to the Client-specific implementation of moveResizeInternal(). To be more specific, the frameGeometry() returns the current frame geometry, it is primarily useful only to the scene. If you want to move or resize a window, you need to use moveResizeGeometry() because it corresponds to the last requested frame geometry. It is worth noting that the moveResizeGeometry() returns the desired bounding geometry. The client may commit the xdg_toplevel surface with a slightly smaller window geometry, for example to enforce a specific aspect ratio. The client is not allowed to resize beyond the size as indicated in moveResizeGeometry(). The data flow is very simple: moveResize() updates the move/resize geometry and calls the client-specific implementation of the moveResizeInternal() method. Based on whether a configure event is needed, moveResizeInternal() will update the frameGeometry() either immediately or after the client commits a new buffer. Unfortunately, both the compositor and xdg-shell clients try to update the window geometry. It means that it's possible to have conflicts between the two. With this change, the compositor's move resize geometry will be synced only if there are no pending configure events, meaning that the user doesn't try to resize the window.
2021-04-30 18:26:09 +00:00
2020-07-11 16:40:28 +00:00
private:
void showTopLevel(OutputInterface *output, InputPanelSurfaceV1Interface::Position position);
2020-07-11 16:40:28 +00:00
void showOverlayPanel();
void reposition();
void handleMapped();
void maybeShow();
2020-07-11 16:40:28 +00:00
QRectF m_windowGeometry;
Mode m_mode = Mode::None;
bool m_allowed = false;
bool m_virtualKeyboardShouldBeShown = false;
const QPointer<InputPanelSurfaceV1Interface> m_panelSurface;
2020-07-11 16:40:28 +00:00
};
}