Before this patch, configuring a surface with a new size,
immediately followed up by one or more view_move() calls
would move the surface to the new coordinates immediately
without waiting for the resize. This caused visual glitches
when for example dragging a maximized window: the position
would change but the size was still that of a maximized
window.
This patch fixes that by just ignoring view_move() requests
(but still updating view->pending) if there is a configure
request pending. Once the client commit comes in the new
size will be applied as usual.
It was not working before because in the case of wayland
we are only dealing with sizes as wayland has no notion
of a global position. A wayland client would thus not
necessarily respond to a configure request which sets
the same size again. This causes us to also not apply
a new position set in view->pending because there may
be no commit from the client in those cases.
We previously worked around this issue in some parts
of the code to check our new sizes against the pending
ones and if they were the same we would call view_move
instead. That had two issues:
- Not all parts of the code did that which could end up
delaying the positioning either to the next completely
unrelated xdg commit event or to the next view_move call
- The code started to repeat itself, e.g. the same condition
with calls to either view_move or view_move_resize based
on the result
This patch fixes it by doing the check in the xdg configure
handler instead. Xwayland is unaffected by this issue as we
are always configuring a xwayland client with both, position
and size.
This is necessary because wlroots backported a patch containing
cursor name aliases to the 0.16 branch. That internal mapping
does not alias "grab" to "grabbing" because it is not technically
part of the cursor-names spec.
To keep the "grab" cursor working on systems with no cursor theme
available (or in an unusual location) change the trigger for our
internal cursor name aliasing to "grab".
See wlroots commit 1e345c74c3ca5d2575aa975d4d9af87cd0c7ba13
Alias existing cursor defaults to cursor-spec cursor names
for further details.
This PR allows applications to activate themselves *if they provide
a valid xdg_activation token* (e.g. raise to the top and get keyboard
focus).
These tokens are given out by the xdg_activation protocol implemented
by wlroots and can be configured by the client requesting the token
in three ways:
- an "empty" token
(apparently used to tell the compositor about "urgency")
- seat / input serial attached
- surface attached
Wlroots makes sure that
- If the client attached the seat / input serial: those two are valid.
- If the client attached a surface: that it has keyboard focus at the
point where the request is finalized. There is a patch [1] pending
for backport to wlroots 0.16 that also allows valid tokens when the
supplied surface had cursor focus.
- a token is only valid for 30 seconds after being given out
The token can then be used by the client or given to other clients by
unspecified means (e.g. via environment variable or dbus) which then
may use the token on their own surface and request activation.
We only handle the actual request activation part:
- If the seat is set on the token we know wlroots validated seat and
input serial
- Thus, if no seat is set we deny the activation request so we don't
have windows suddenly popping up and taking over the keyboard focus
(focus stealing prevention)
- We should also check for the surface being set but we can't do that
with wlroots 0.16 as it will reset the surface to `NULL` when it is
destroyed (which is something that usually happens for
notifications). Once we move to wlroots 0.17.x we can add the
missing surface check because it provides a `new_token` signal.
We can use it to attach further details to the token which are then
verified later when we decide if we allow the activate request or
not.
With this PR in place the following setup should activate windows:
- launching an URL in foot should activate the target application if
it is already running, foot requests a proper token and then sets it
as `XDG_ACTIVATION_TOKEN` environment var before spawning `xdg-open`
- clicking on a `mako` notification with a `default` action defined
should request a proper token which is then given to the application
starting the notification and can thus be used to activate itself
This protocol is still very much in the process of being
implemented / finalized all over the place (e.g. GTK / QT / Firefox /
notification daemons, ..) but we should do our part and remove labwc
from the puzzle of potential issues causing this not to work.
[1] f6008ffff4)
- Don't overwrite pending size in map() if it was already set
- Don't reposition view in map() if maximized/fullscreen
Also, as future-proofing in case we one day allow initially-tiled views,
replace explicit maximized/fullscreen checks with view_is_floating().
If xdg_toplevel_view_move() is called when a resize is pending
(e.g. after xdg_toplevel_view_resize() but before handle_commit()),
the newer x/y coordinates passed to move() should take precendence
over the older pending_move_resize.x/y coordinates.
This is consistent with the logic used in xwayland.c's move().
struct view's pending_move_resize.update_x/update_y flags appear to
be redundant, since we can easily determine whether x/y have been
update via a simple comparison in handle_commit().
The only corner case I can think of where this change might affect
behavior, is if xdg_toplevel_view_move() is called while a resize
is still pending (e.g. after xdg_toplevel_view_configure() but
before handle_commit()). This corner case will be addressed in the
following commit.
The wlroots wlr_output_layout provides two different modes of operation:
- automatically
- manually
In automatic mode wlroots reacts to new / removed outputs and resolution
changes and then adjusts the output positions within the layout itself.
The manual mode disables this behavior and thus it is the whole
responsibility of the caller (e.g. us relaying whatever wdisplays /
kanshi provides) to ensure that the layout is somewhat sane. E.g. that
it doesn't have any holes between outputs and there are no overlapping
outputs.
The mode is set for each output individually. To use (and keep using)
the automatic mode, outputs have to be added via the _add_auto() variant
(which we do) and they are not allowed to be moved via _move() (which
we currently do and thus break the automatic layout).
To fix that, this patch compares the user (tool) supplied position to the
automatically calculated position and only if they differ we call _move().
- Process layer-shell keyboard interactivity in the map and commit
handlers only, rather than in layers_arrange(). This allows handling of
the layer-surface that emitted the event rather than iterating over all
surfaces in the output layer-tree, and therefore avoids having to guess
which surface should have keyboard preference (and it might not be the
last one added to the list which was the assumption previously).
- Prevent seat_focus_surface() from setting keyboard focus if a layer-shell
surface with exclusive keyboard-interactivity has the focus.
- Set cursor_context type for layer-surfaces without node-descriptors
in order to set keyboard focus correctly in cursor_button_press().
Tested satisfactorily with xfce4-panel and gtk-layer-demo.
Fixes#725 and #704
- Move xwayland-specific struct definitions to new xwayland.h header
- Move xwayland_move_sub_views_to_front() from desktop.c to xwayland.c
- Split out xwayland_server_init/finish() from server_init/finish()
- Rename new_xwayland_surface -> xwayland_new_surface and
xwayland_surface_new() -> handle_new_surface() for consistency
- Add "mapped" argument to xwayland_unmanaged_create() so that we can
make unmanaged_handle_map() private to xwayland-unmanaged.c
This restores the original approach of naming the argument `layout_changed`
which fits much better than `enforce_view_arrange`. Especially when extending
the function to also handle region updates once merged.
Move the desktop_arrange_all_views() call outside layers_arrange() into
a new function, output_update_usable_area(). The new function currently
does exactly what layers_arrange() used to, but will be expanded in a
later commit.
Add output_update_all_usable_areas(), which is the same as calling
output_update_usable_area() for each output, but only calls
desktop_arrange_all_views() once.
Rebased and slightly modified by @Consolatis
...by reading <config-dir>/themerc-override where <config-dir> is normally
$HOME/.config/labwc can be other locations as described in labwc-config(5)
and can also be specified by the command line option -C.
The reason for supporting theme override is to give users more fine-
grained control of settings without making local copies and modifying
themes.
