Instead of killing the window without asking, show the kill prompt
like it's done for X11 windows.
The window in question is exported through XDG foreign so the kill
helper can parent itself to it, and an activation token is also provided.
Also, the more contemporary desktop file name is now used for
identification rather than window class.
A no-display desktop file is installed for the kill helper so that it
can get a proper window icon and suppress startup notification.
With LayerShell all docks were in the above layer to match with the
semantics of the specification. Under X11 our main panel was also in the
above layer by setting the keep above flag.
The only thing that ended up in the dock layer were wayland applet
popups, and that was mostly by accident. When they get a transient
parent fixed they'll end up in the AboveLayer anyway so we should drop
it now to reduce complications.
This fixes a bug where applet popups could go under the panel.
BUG: 465354
This makes unconstraining code more reusable (in case of applet popups
use xdg-positioner too), and in general, it makes sense for better
encapsulation.
Ensures that e.g. context menus move about with their parents when they
get moved around.
However, as per spec don't re-constrain the window when its positioner
is non-reactive. This change calculates the offset from its parent window
once initially and places the window relative to that whenever the parent
moves.
Only when the positioner is reactive, will it recalculate the placement fully.
BUG: 461994
This change adds support for xdg_wm_base v6, which introduces
xdg_toplevel suspended state.
The suspended state is tied to the visibility of the window item so the
effects could possibily "resume" window content updates.
In v5, the xdg_toplevel.wm_capabilities event had been introduced which
specifies a list of actions allowed by the compositors. Mainly useful to
client-side decorated apps.
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.
Window::handleInteractiveMoveResize() calls setMoveResizeGeometry(),
which breaks in a way the encapsulation.
This change refactors geometry handling in handleInteractiveMoveResize()
so the next geometry is computed in a temporary variable and the move
resize geometry is updated either using move() or
doInteractiveResizeSync().
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.
There are a few benefits to using smart pointers from the standard library:
- std::unique_ptr has move semantics. With move semantics, transfer of ownership
can be properly expressed
- std::shared_ptr is more efficient than QSharedPointer
- more developers are used to them, making contributions for newcomers easier
We're also already using a mix of both; because Qt shared pointers provide
no benefits, porting to standard smart pointers improves consistency in
the code base. Because of that, this commit ports most of the uses of QSharedPointer
to std::shared_ptr, and some uses of QScopedPointer to std::unique_ptr
