* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
maliit creates a fullscreen overlay window which doesn't go along well
with out geometry abstractions. For example, raw frame geometry can't be
used to displace normal windows otherwise they will be pushed offscreen.
Some of the maliit quirks are leaked in the InputMethod class. After
extending the lifetime of the InputPanelV1Window, they can cause
problems.
In order to make code in InputMethod more intuitive and encapsulate
maliit quirks, this change makes InputPanelV1Window interpret the
bounding rectangle of the input shape as the window geometry. This
lets us get rid of the hack in inputGeometry() too.
The size checks in Mode::VirtualKeyboard case have been removed because
they should be irrelevant. When reposition() is called, the wl_surface
is mapped, so its size cannot be 0x0.
Currently, the normal window lifecycle looks as follows: create Window,
wait until it's shown, add it to Workspace, wait until it's closed,
create a Deleted, copy properties from the original window to the
deleted one, destroy the original window, wait until the last deleted
window reference is dropped.
There are a couple of issues with this design: we can't nicely
encapsulate X11 or Wayland specific implementation details if they need
to be accessed for closed windows; manual copying of properties is
cumbersome and error prone and we've had a dozen of cases where effects
worked incorrectly because some properties had not been copied.
The goal of this patch is to drop Deleted and extend the lifetime of the
original window, but with a special state set: Window::isDeleted().
The main danger is that somebody can try to do something with deleted
windows that they should not do, but on the other hand, such code needs
to be guarded with relevant checks too.
It's needed to work around the cleanup logic of decorations.
Currently, decorations have a valid QObject parent and they're managed
using std::shared_ptr. That's not a perfect combination, but changing it
is also going to be an involved task because the QObject parent is used
to look up the Window.
In long term, it won't matter since we want to get rid of Deleted.
For what it's worth, it restores the order in which Deleted and normal
windows used to be destroyed prior to
995d509e45.
Window::depth and Window::hasAlpha make no sense on Wayland. The main
reason why we can't rid of them completely yet are X11Window and
Unmanaged.
This change makes WaylandWindow initialize depth to 32 by default to
make wayland window subclasses less boilerplaty.
While there's specific hardware where the IM could benefit from requesting to
be shown on a specific output, it effectively never has enough information to
choose a useful output - and the protocol doesn't allow setting a null output
to indicate that the compositor should do the choice.
To avoid showing the OSK on the wrong output, always put it on the active
output and ignore what the IM client requests.
Main reason to support this old interface is because this is the only
protocol chromium (and effectively all electron app) that supports.
The protocol itself very similar to text-input-v2 with some minor difference.
So not hard to support by just duplicate some existing code. There might be
some unclear protocol design issue if kwin need to support multiple SeatInterface,
but for now it should be ok to assume there is only one seat.
Tested using fcitx5 against weston-editor and chromium with flag
--enable-features=UseOzonePlatform --ozone-platform=wayland
--enable-wayland-ime
Due to being a compositor, kwin has to conform to some certain
interfaces. It means a lot of virtual functions and function tables to
integrate with C APIs. Naturally, we not always want to use every
argument in such functions.
Since we get -Wunused-parameter from -Wall, we have to plumb those
unused arguments in order to suppress compiler warnings at the moment.
However, I don't think that extra work is worth it. We cannot change or
alter prototypes in any way to fix the warning the desired way. Q_UNUSED
and similar macros are not good indicators of whether an argument is
used too, we tend to overlook putting or removing those macros. I've
also noticed that Q_UNUSED are not used to guide us with the removal no
longer needed parameters.
Therefore, I think it's worth adding -Wno-unused-parameter compiler
option to stop the compiler producing warnings about unused parameters.
It changes nothing except that we don't need to put Q_UNUSED anymore,
which can be really cumbersome sometimes. Note that it doesn't affect
unused variables, you'll still get a -Wunused-variable compiler warning
if a variable is unused.
Instead of InputMethod directly calling showClient() on the input panel,
call methods that properly show or hide the panel as needed, with readyForPainting
set appropriately. This removes the cases where it's shown without being ready for
painting, which causes crashes.
BUG: 459404
Things such as Output, InputDevice and so on are made to be
multi-purpose. In order to make this separation more clear, this change
moves that code in the core directory. Some things still link to the
abstraction level above (kwin), they can be tackled in future refactors.
Ideally code in core/ should depend either on other code in core/ or
system libs.
With fractional scaling integer based logical geometry may not match
device pixels. Once we have a floating point base we can fix that. This
also is
important for our X11 scale override, with a scale of 2 we could
get logical sizes with halves.
We already have all input being floating point, this doubles down on it
for all remaining geometry.
- Outputs remain integer to ensure that any screen on the right remains
aligned.
- Placement also remains integer based for now.
- Repainting is untouched as we always expand outwards
(QRectF::toAdjustedRect().
- Decoration is untouched for now
- Rules are integer in the config, but floating in the adjusting/API
This should also be fine.
At some point we'll add a method to snap to the device pixel
grid. Effectively `round(value * dpr) / dpr` though right now things
mostly work.
This also gets rid of a lot of hacks for QRect right and bottom which
are very
confusing.
Parts to watch out in the port are:
QRectF::contains now includes edges
QRectF::right and bottom are now sane so previous hacks have to be
removed
QRectF(QPoint, QPoint) behaves differently for the same reason
QRectF::center too
In test results some adjusted values which are the result of
QRect.center because using QRectF's center should behave the same to the
user.
`bottomLeft()` is affected by the same issue as anything else using
bottom, that is, it is off by 1. So instead use top() + height() for the
bottom edge.
This makes KWin switch to in-tree copy of KWaylandServer codebase.
KWaylandServer namespace has been left as is. It will be addressed later
by renaming classes in order to fit in the KWin namespace.
AbstractOutput is not so Abstract and it's common to avoid the word
"Abstract" in class names as it doesn't contribute any new information.
It also significantly reduces the line width in some places.
With this change, the Workspace would provide clientArea() overloads
that take only AbstractOutput and VirtualDesktop. integer ids are
obsolete as they are unstable.
The .clang-format file is based on the one in ECM except the following
style options:
- AlwaysBreakBeforeMultilineStrings
- BinPackArguments
- BinPackParameters
- ColumnLimit
- BreakBeforeBraces
- KeepEmptyLinesAtTheStartOfBlocks
We should use the output area as the margin size as where to position
rather than the panelSize.
This ensures that the keyboard ends up in the right place right above
the panels.
Rather than assuming the input panel to always be less than or equal to
the maximized area, ensure it is. This ensures that the input panel gets
placed correctly when there maximized area is smaller, like when there's
a panel on the side.
Additionally, don't skip the entire positioning code when "m_output" is
empty, to avoid the placement not happening when Kickoff is open.
Qt usually request InputMethod::hide() upon unfocus, but
InputMethod::show() is actually never called if focus transfer is done
by keyboard, which leads to a permanent disabled input method state.
It can be easily reproduced with a window with two text field, e.g.
QFileDialog, by pressing tab to switch the focused widget.
The semantics of hide/show should not deactivate the input method.
Instead, it should simply hide/show the input panel. Also it should not
be a hard request for input method to permanently hide the window. When
input method asked to show it again, the input panel window should be
shown.
Prefer hiding/showing the panel (i.e. the window) when not a touch event
than stopping to make the inputmethod active.
This way we remain compatible with non-virtualkeyboard inputmethods.
The new overloads take the client (as context) and the desired screen id
or a point and return the client area.
The main motivation behind this change is to make the transition to the
new virtual desktop model where a window can be on several desktops less
painful.
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.
Vlad Zahorodnii
Laurent Montel
Xaver Hugl
Weng Xuetian
Aleix Pol
David Edmundson
Arjen Hiemstra
Rodney Dawes
Bhushan Shah