Sway handles some xwayland events that labwc still does not. This commit
just starts to rig up some handlers for these with log messages if they
are caught.
- set_geometry: try to handle, but cannot find an application that uses
it, so is untested.
- request_activate - just log caught event
- override_redirect - just log caught event
Instead of using the stored view for comparison use the actual surface.
Before this patch, there were situations where the branch intended for
out-of-window text selection / scrollbar dragging was used even though
the cursor never left the surface.
Partly fixes#340
This is needed to allow X11 applications to create surfaces as
non-override_redirect and then change them to override_redirect later
Without this gitk-menus and rofi are treated as xwayland-views with
associated server-side-decoration and forced positioning.
- adds labwc.pot and po files for de, es, it and sv
- added notes in NEWS.md and CONTRIBUTING.md
- addresses #269
- conditional upon `msgfmt` being installed
- can be disabled at build time
Consolidates all of the view destruction code for xwl + xdg into one function.
Fixes several notable bugs along the way:
- Fixes a crash when alt tabbing when a selected view gets destroyed.
- Fixes the OSD not updating to reflect a view has been destroyed.
Commit 08c537e ("xwayland: Honor size increments from
WM_SIZE_HINTS") adjusted only the window width/height according
to the size hints. If resizing from the top or left edge of the
window, we also need to adjust the window position to keep the
bottom or right edge from jumping around.
...and call it from desktop_move_to_front() in order force an enter event
on the surface below the cursor when cycling views.
Fixes#162 and #225
Inspired by PR #164 - just restructured it a bit.
Suggested-by: @bi4k8
Co-authored-by: Consolatis <35009135+Consolatis@users.noreply.github.com>
This allows popups to be rendered above views and other layers. Without
this, the popups of a layer-shell application in the bottom layer would
render below views, which does not seem right. For example, consider the
case of a panel with right-click popups.
Prevents a single action like ToggleDecorations + ToggleMaximize to
position the view somewhere with negative coordinates when unmaximizing.
It may still position the view on negative coordinates but later commit
events will fix the position. This issue only exists on xwayland because
there are no configure serials which we could use to ignore all
repositioning until we are at the latest desired state.
Use view_move() and view_move_resize() correctly.
view_move_resize() should only be used when the view actually changes
width and/or height, otherwise the serials might cause a delay in moving
xdg-shell clients.
Issue #201
labwc currently doesn't handle output layout changes very well:
- Windows can end up "lost" completely offscreen
- Maximized/fullscreen windows can end up spanning multiple outputs
Currently, new_output_notify() and output_destroy_notify() contain logic
to update the cursor and force a repaint when outputs are added or
removed. This logic in fact needs to run on any output layout change,
so consolidate it into a new function, output_update_for_layout_change().
Then add a second new function, view_adjust_for_layout_change(), which
adjusts window placement to account for the new layout.
The behavior is roughly as follows:
- Normal windows that end up offscreen are centered on the closest
output (making use of the existing view_center() logic)
- Maximized windows are re-maximized on the closest output. Logic is
also added to the unmaximize step to check that the original
unmaximized position is still on-screen.
- Fullscreen windows are re-fullscreened on the same output if
possible; otherwise they are un-fullscreened.
Minimized windows don't require any special handling. Their placement
is adjusted just the same, but invisible to the user until they are
later unminimized.
There is some positioning glitch still with un-fullscreening a window
whose output has been disconnected/disabled; it can end up in an
unexpected position (but at least has the correct size and decoration).
I don't think this is due to a bug in my change per se, but perhaps the
change has exposed a bug elsewhere.
Fixes: #177
...and call it from desktop_move_to_front() in order force an enter event
on the surface below the cursor when cycling views.
Inspired by PR #164 - just restructured it a bit.
Suggested-by: @bi4k8
If we don't switch focus, we want the close button to close the window associated with it, not the current focus window.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
