The topmost view may not always be the focused view; for example,
when Audacious's main window is focused but the floating Search
Tool window remains on top of it. In that case the floating window
(not the main window) should be the first view selected in the
window switcher.
- When XDG and XWayland views are positioned (view_moved()).
- When unmanaged XWayland surfaces are mapped, unmapped, or moved.
Do not update cursor focus during an out-of-surface drag.
Along with the existing call in desktop_move_to_front(), this
should hopefully cover the majority of cases where the cursor focus
could get out-of-date, with the possible exception of layer-shell
surfaces.
At least for XWayland surfaces, handle_commit() is not always
called after map(), and as a result, the scene-graph node is never
positioned.
Not sure 100% if the same can occur with XDG surfaces, but the
extra view_moved() call should be harmless, so add it there too
for consistency.
- Eliminate multiple "return" paths in unmanaged_handle_unmap(), which
were a bug waiting to happen.
- Use wl_list_for_each_reverse() rather than wl_list_for_each() to find
the topmost (most-recently-created) unmanaged surface.
- Only call desktop_focus_topmost_mapped_view() if the unmapped surface
was actually focused.
Previously, when unmapping and not finding another unmanaged surface
to give keyboard focus to we were not doing anything. With this patch
we will give focus to the topmost mapped view which is the same
behavior that also happens when an usual X11 surface unmaps.
This fixes dmenu when being exited with ESC.
Reported-by: @Flrian
This loads default mousebinds and provides a way to keep config files
simpler whilst allowing user specific binds.
Note that if no rc.xml is found, or if no <mouse><mousebind> entries
exist, the same default mousebinds will be loaded even if the <devault />
element is not provided.
Example usage (with a slight spelling error):
<mouse>
<default />
<context name="Root">
<mousebind button="Right" action="Press">
<action name="ShowMenu" menu="desktop-menu" />
</mousebind>
</context>
</mouse>
Co-Authored-By: @johanmalm
Fixes#416
Before this patch, minimizing the last un-minimized window would
not cause it to be set to inactive. This in turn would confuse panels
which depend on the 'active' flag to decide when to either activate or
minimize the clicked on window.
Reported-by: @Flrian
Predicted-by: @johanmalm
To update the wlroots subproject use
meson subprojects update wlroots
Chases wlroots fa7d2cb8d60ed48c44c707106c03682056ddfaca
wlr_scene: Only consider visible parts of the node when culling background
Fixes#501
This makes the border visible when alt-tabbing maximized windows and
prevents it from rendering on other outputs or on top of exclusive
layer-surfaces such as panels.
Closes issue #496
...when pointer moves off the xdg-shell surface which is possible when
for example grabbing a scroll-bar or selecting text.
Clamping results in undetected pointer motion when applied in the
direction of movement (for example clamping at view->y masks vertical
movement when the y-coordinate is greater than view->y), which in turn
can appear as sporadic to the end-user.
Previously, motion events for a cursor which had been pressed on a surface
and then moved out of the surface were only sent for XDG and X11 surfaces.
This patch includes layer surfaces as well.
Fixes#483
X11 apps expect to be able to receive motion events outside
the window area (this is necessary for client-side move/resize
handles to work properly). So do not clamp the motion
coordinates for XWayland surfaces.
Before this change, attempting to enlarge an XWayland window
using a client-side resize handle resulted in the window size
lagging behind the mouse cursor quite severely, since each
motion event was in effect allowed to expand the window by
only a few pixels. The closer the initial button-press was
to the edge of the window, the worse the lag would be.
Before this commit the window title could overflow in certain conditions,
usually when rapidly resizing. This commit fixes it by completely hiding
the corresponding scene node when there is no space available.
Reported-by: <peperino> via IRC
Allow highest level menu definitions - typically used for root-menu and
client-menu - to be defined like this:
<openbox_menu>
<menu id="">
</menu>
</openbox>
Previously this required a label attribute (which was not used for
anything and could be an empty string) as show below:
<openbox_menu>
<menu id="" label="">
</menu>
</openbox>
Closes issue #472
