XdgPopupWindow disregards it for the most part anyway and asks workspace
for the placement area directly. Also gives XdgPopupWindow more control
on the placement when it's all contained inside of it for the upcoming commit.
Selection acts as an abstraction around multiple X11Sources, when we get
a new source we asyncronously emit that x11OffersChanged when it
completes.
If the selection is lost, we were just deleting the source, without
notifying other parts.
XwlDataSource is the datasource that SeatInterface knows about. We need
to delete this when the X11 connection is no longer valid. SeatInterface
will update the selection when the XwmlDataSource is deleted if it's the
active selection.
The hook is introduced as updating the selection in Clipboard will cause
Selection to delete m_xSource which gets messy.
BUG: 449909
The preview item implements hover event filters, which by default
are accepted and not propagated to their parent, breaking the
hightlight on hover for the GridView.
We can simply "ignore()" those events so they are propagated,
but still fully functional.
Preemptively, do the same also for mouse events, which seem to be
already propagated now, but shouldn't according to the QQuickItem
documentation.
CCBUG: 473011
While not common a client can have bound the global multiple times
and create window objects through all of them. In this case the event
send to the client would carry the wrong object since only the clients
of the two resources were checked for equality.
We can save the resource of the window managment the window
belongs to by extending the resource and storing it there.
Sending the initialState has been moved out of resource_bind since
it happens directly after allocate() and there being no opportunity
to set the custom wmResource field in between.
Instead of hardcoding ARGB8888 and using implicit modifiers, look through
the list of available formats and modifiers and pick a match that egl will
actually accept.
Given how the blur effect works, if a pixel changes, the surrounding
pixels may have to be repainted as well. Currently, it's achieved by
expanding the damage in the BlurEffect::prePaintWindow() function.
However, it means that the blur effect should see both surface and
buffer damage in the pre paint pass.
Unfortunately, after refactoring surface and buffer damage tracking,
kwin no longer provides the buffer damage in the pre paint pass (it does
so for good reasons). This broke the blur effect. As an example, you may
see visual glitches when moving the software cursor over blurred areas
of a window.
In order to fix this issue, the blur effect has to cache background
behind every window to avoid blurring already blurred areas.
This change implements a background cache. Unfortunately, since the
blur effect's code has become very difficult to change over the years,
this change rewrites the relevant parts of the blur effect.
With the proposed design, the blur effect is going to maintain cached
background for every window + offscreen render targets. It may have
issues with animated windows, however in practice, it seems to behave
good enough. However, if it becomes pressing matter, we can move from
simplistic design in this patch to somewhat more sophisticated design
that involves textures with rounded up size.
BUG: 455526
At the moment, the blur effect operates in two modes:
- generic where the blur effect samples from pixels outside the window
- and a more strict version where the blur effect only blurs what's
behind the window
The latter mode is preferred for panels and its popup. However, it also
makes sense to enable this mode for normal windows too. This simplifies
the blur effect a bit.
modifiersRelevantForTabBox handles modifiers being consumed, which is wrong for the
tabbox; all it needs is to ignore capslock. To ensure that happens, this commit adds
a separate method for modifiers relevant for the tabbox.
BUG: 473099
Specification for data control states:
"The first selection event is sent upon binding the
wlr_data_control_device object."
This differs to other data devices.
CCBUG: 459389
The show_window_menu request is in surface-local coordinates,
which include any client-side window shadows.
Translate the menu coordinates so the window shows up in the
right spot.
At commit time, the newest commit that's ready will be chosen, ensuring that
cursor updates added just before commit time can't delay the primary plane
update unnecessarily
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.
`Placements::placeSmart` searches for an optimal position for windows, attempting to minimize overlap. The core of this algorithm tracks the
client's height and width in `ch` and `cw`, which have been adjusted by -1. This simplifies logic determining the bottom and right points of a
window when you are starting at the top and left points.
However, this decision requires adjusting that number by +1 when doing the opposite: determining the top and left points when you start with
the bottom and right points.
placeSmart cycles through window locations, searching for acceptable nooks and crannies to fit a window in, nicely. It begins by checking
for places to put the top left corner of the window which abut another constraint. If that fails, it then tries to place the bottom right
abutting a constraining feature.
After finding a suitable bottom (or right) location, the top (or left) location must be determined, requiring the -1 adjustment to be undone.
This patch adds that +1 back in.
# The bug it solves
This error can be seen by opening a bunch of windows that are placed using the "Minimal Overlapping" rule. The open space on the screen will be tiled from left to right, and then top to bottom in the windows. Once no more windows can be placed like that, the next window will be placed at the extreme bottom-right corner. However, it will be one pixel too low and one pixel too far to the right---if you try to move the window, it will "snap" to the correct spot.
This single pixel may seem minor or even irrelevant, but when you use the "Present Windows" desktop effect on a multiple-monitor setup, this one pixel will cause the window to show up on both monitors.
