Ref: 515275ee7214bf91f8a758b660093eb4b932195a
(wlr_scene: Introduce wlr_scene_set_gamma_control_manager_v1)
This wlroots change eliminates the need for separate event tracking for gamma
control application.
v2: Fix code style
v3: Rebase now that 0.20 is merged
Ref: 84d603acc06a45dd3c3a4b2cf1fd08b2933ca2b5
(xwayland: take wlr_buffer in wlr_xwayland_set_cursor())
Ref: 6ae54dca23064e897b393283887986e5719a747f
(xwayland: lock new buffer instead of the old one)
Co-Authored-By: Consolatis
This wlroots change fixes a potential UAF which we dealt with in labwc.
We can thus remove the workaround completely.
Empirically, the associate event is always seen just after map_request
but before surface map. Window properties are also read by wlroots just
before emitting associate. So after some trial and error, this seems to
be the best place to set initial view states and compute initial
placement.
Fixes initial positioning of "urxvt -g -0-0".
urxvt placement regressed in:
9903331995
("xwayland: rework setting initial geometry from surface")
map_request handler was added ~2 years ago in:
c9018da4c4
("xwayland: set initial geometry in map_request handler")
I'm not sure if the map_request handler was incorrect from day one,
or if something changed in wlroots and/or Xwayland since then.
The basic idea is to set the initial geometry from the surface exactly
once, just before we need it, i.e. either (1) when mapping the view or
(2) right before processing an initial maximize/fullscreen request.
I've consolidated various parts of the initial geometry setup to take
place at this point (in ensure_initial_geometry_and_output()).
The main motivation is to have a valid, adjusted floating geometry for
the view *before* saving the natural geometry when processing an initial
maximize/fullscreen request. This reduces code duplication and addresses
a FIXME in set_initial_position(), as well as fixing an issue where the
natural geometry could exceed the usable output area.
Some other minor changes:
- The initial output is now set directly from the surface geometry if
the "application/user-set position" hint is given. This is unlikely
to matter in practice, but theoretically an initially maximized view
could now appear on a different (application-chosen) output.
- Floating view size is now constrained to the usable area even if a
position hint is set. It seemed inconsistent that `xterm -g 200x200`
was constrained but `xterm -g 200x200+0+0` was not.
wlr_scene_*_create() functions all allocate memory via calloc() and
return NULL if the allocation fails. Previously, the failures were
handled in any of 3 different ways:
- sending a wayland protocol error
- exiting labwc with an error
- segfault (no NULL check at all)
Since labwc does not attempt to survive heap exhaustion in other
allocation paths (such as `znew`), it seems more consistent to use the
same die_if_null() check used in those paths to exit with an error.
For the three most common create() functions (tree, rect, buffer),
add small lab_wlr_ wrappers to common/scene-helpers.
Fix a regression introduced in 3f223fe5 where output layout changes may
move xdg views outside of the output layout with the error:
`view has no last placement info`. This happens also for X11 views if
they don't specify its own geometry on map.
Recent changes introduced `view->last_placement` which is used to
restore view positions after layout changes. This is supposed to be
updated when a view is mapped or manually moved by the user.
However, 3f223fe5 replaced `view_place_by_policy()` with
`view_compute_position_by_policy()` in the xdg view map handler. Unlike
`view_place_by_policy()`, this function does not update
`view->last_placement`, leaving it unset at the time of output layout
changes.
Therefore, this patch adds explicit calls to `view_save_last_placement()`
in the map handler to ensure `view->last_placement` is always set for
mapped views.
- Add `server` argument to `interactive_set_grab_context()` to clarify
it updates something in `server`.
- Add `const` qualifier to `ctx` argument of
`interactive_set_grab_context()` and `cursor_get_resize_edges()`
When a opening a layer-shell popup via IPC (like `lxVqt-qdbus openmenu` or
`xfce4-popup-applicationsmenu`), give keyboard focus to the popup, not the
parent layer-shell surface.
Written-by: @tokyo4j
...in support of enabling panel menus to be opened by keyboard shortcuts
and get keyboard focus so that they can be operated with the keyboard.
An example use-case is the xfce4-panel applications-menu being opened by
the command xfce4-popup-applicationmenu.
Before this commit, always-on-{top,bottom} windows were always visible
on all workspaces (omnipresent) because the they were not in
per-workspace trees like normal windows.
This commit fixes this by introducing per-layer trees in
`struct workspace`.
I also added `enum view_layer` and `view->layer` for simplicity.
Add interactive_set_grab_context() which is called when the mouse button
is first pressed, before interactive_begin(). This fixes two small issues:
- The cursor origin position for interactive move/resize was slightly
off (depending on mouse resolution), because it was set after the
mouse had already moved slightly. Now it's exact.
- If app- or keybind-initiated maximize (etc.) happened after the button
press but before the mouse was moved, then interactive_begin() would
still start move/resize even though the view might now be far away
from the cursor. Now interactive_cancel() works as expected, even if
called before interactive_begin().
Also, make sure to call interactive_cancel() for un-maximize as well.
f58b532 implemented output-relative position saving/restoring on output
un-plugging/re-plugging. It worked as follows:
1. Store the output-relative view geometry in `view->last_placement`
(if not set) before adding/removing an output from the layout.
2. After adding/removing an output, call `view_adjust_for_layout_change()`
after the layout change to restore the output-relative view geometry
based on `view->last_placement`.
However, it didn't consider `view_adjust_for_layout_change()` being
called from other places such as `regions_reconfigure()` and
`output_update_all_usable_areas()`, causing an error message "view has
no last placement info". This can happen when a panel is mapped or
unmapped, or on Reconfigure.
This commit fixes it by changing the life cycle of
`view->last_placement`. It used to be set only before output layout
changes and cleared on user-initiated moves/resizes, but now it is set
and updated on user-initiated moves/resizes. I think this is more
intuitive, too.
Fixes a regression in 83b619c2 that the bottom-most view is focused
when when an exclusive layer surface (e.g. fuzzel) is unfocused.
Also, added some comments to clarify the order.
