| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
Add an option for the `hide_cursor` command to hide the cursor when
typing, i.e. whenever a key is pressed.
|
| |
|
|
|
|
|
|
| |
The function evacuate_sticky() was changed in commit 32788a93 to be used
by workspace_for_each_container() to make the code more readable. But I
overlooked that it is not safe to use workspace_for_each_container() to
remove container from a workspace. This commit restores the previous
implementation for evacuate_sticky().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when a floating container with a view is split and
children are added to it, the new views are rendered as tiled,
while the first view stays in floating style.
Here this is addressed by setting the view to tiled as soon
as the container is split, by duplicating the "view part" of
the logic in container_set_floating(..., false). Since the new
container of the view is no longer considered floating, it
makes sense to set the view to tiling at this point.
The view would have to be set back to floating if it was possible
to "unsplit" the container.
|
| |
|
|
|
|
|
| |
Sticky floating containers on an otherwise empty workspace can only be
evacuated if the new output has an active workspace. The noop output may
not have one and in that case we have to move the whole workspace to the
new output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, in view_autoconfigure, the only condition for show_border
is !view_is_only_visible. view_is_only_visible does not cross the
boundary between the workspace's tiling and floating lists and does not
differentiate between them.
The result is, that in a workspace with zero or more tiling containers
and a single floating container, the floating container will lose its
borders as soon as it is split, provided that a only one view is visible
within the floating container.
Fixed by adjusting the condition for show_borders.
|
| |
|
|
|
|
|
| |
Reset the workspace layout to the output's default only if the workspace
is actually attached to an output.
Fixes #5762
|
| | |
|
| |
|
|
|
|
| |
A "resize shrink width 1px" will cause grow_x to be 0 while grow_width is -1,
incorrectly rejecting the command even though the resize is not a noop. Fix
this by checking width/height instead of x/y.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sway maintains a list of pending transactions, and tries to merge
consecutive transactions applying to the same views into one. Given
a pending transactions list on views {A, B, C} of:
A -> A' -> A'' -> B -> B' -> B''
Sway will collapse the transactions into just A'' -> B''. This works
fine when doing things like resizing views by their border. However,
when interactively resizing layouts like H[V[A B] C], we end up with
pending transaction lists like:
A -> B -> C -> A' -> B' -> C' -> A'' -> B'' -> C''
Previously, Sway would not be able to simplify this transaction list,
and execute many more transactions than would be necessary (the final
state is determined by {A'', B'', C''}).
After this commit, the transaction list gets simplified to A'' -> B'' ->
C'', resolving performance problems (that were particularly noticeable
with high-refresh-rate mice).
Fixes #5736.
|
| |
|
|
|
|
|
|
|
|
|
| |
Xwayland views are aware of their coordinates, so validating transaction
completions should take into account the reported coordinates of the
view. Prior to this commit they didn't, and matching dimensions would
suffice to validate the transaction.
Also introduced `transaction_notify_view_ready_immediately` to support
the fix from d0f7e0f without jumping through hoops to figure out the
geometry of an `xdg_shell` view.
|
| |
|
|
|
|
|
|
|
| |
Sway logical coordinates are doubles, but they get truncated to integers
when sent to Xwayland through `xcb_configure_window`. X11 apps will not
respond to duplicate configure requests (from their truncated point of
view) and cause transactions to time out.
Fixes #5035.
|
| | |
|
| |
|
|
|
|
| |
Closes #5735, refs #3007.
This makes the "Search everywhere" dialog in JetBrains IDEs movable.
|
| | |
|
| |
|
|
| |
Closes #4139.
|
| |
|
|
|
|
|
|
| |
It is recommended that mouse and lens cursor tool default to relative
mode and all pen-like tools to absolute mode.
Refs
https://wayland.freedesktop.org/libinput/doc/1.11.3/tablet-support.html#tablet-relative-motion.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Prior to this commit, having a layout like T[app1 V[app2]], focusing
app2, and then doing `move left` would result in T[app2 app1]. Now, the
resulting layout is T[app1 app2], which matches i3 behavior.
`container_flatten` updates `container->parent`, meaning that the
existing check would never be true.
|
| |
|
|
|
|
|
|
|
| |
i3 shows indicators for the workspace-level pseudo-split, but Sway does
not, as of b977c02. This commit replaces the floating container check
with a call to `container_is_floating`, which has some more robust
checks in place.
Fixes #5699.
|
| |
|
|
|
|
| |
output
Fixes #5668
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We can't arm the timer during cursor creation since the config may not
be ready yet. Instead arm the timer while applying the input
configuration, by this time the configuration has been parsed and we can
arm the hide timer.
Fixes #5686
|
| |
|
|
| |
See https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/486
|
| |
|
|
|
|
|
|
|
|
| |
According to the wayland docs, wayland timers are disarmed on creation.
This leads to the cursor not being hidden if there is no activity after
creation, since the timer is armed on activity, but not at creation.
Arm the timer after creation to ensure the cursor is hidden even if
there is no cursor activity after creation.
Fixes #5684
|
| |
|
|
|
|
|
| |
Otherwise, Sway will not re-hide a cursor after the last button has been
released.
Needed alongside afa890e to fix #5679.
|
| |
|
|
|
|
|
|
| |
Reset the event source after unhiding the cursor, to ensure that the
timeout starts after showing the cursor. Also remove the open coded
variant in seat_consider_warp_to_focus().
Fixes #5679
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My primary issue was IntelliJ IDEA's code suggestion pop-up not returning focus
to the active editing window.
I have spent some time looking at the changes of @Xyene (#5398) and
@RyanDwyer (#2103). I think my proposed change maintains the status
quo for the most part whilst fixing my focus issue.
I have verified that @Xyene's fix for IntelliJ sub-menus still works.
I have done basic testing which consists of:
- Chrome
- IntelliJ IDEA 2020.2.1
- VSCode
- Alacritty
It seems to hold up. I at least didn't see any obvious errors.
Relates to #3007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes it so all libinput config options are set on any device
that supports it. Previously, only a subset of libinput config options
were being considered depending on the input type. Instead of trying to
guess which properties the device may support, attempt to set any
configured property regardless of the device type. All of the functions
already have early returns in them for when the device does not actually
support the property. This brings the configuration side inline with
describe_libinput_device for the IPC side. This change was prompted
by a tablet tool showing the calibration matrix property in the IPC
message, but not being able to actually change it since that property
was only being considered for the touch input type.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of listening to both transform and scale events, we can listen
to the commit event and use the new wlr_output_event_commit struct to
decide what to do.
This de-duplicates some of the work we were doing twice when an output
was re-configured.
Depends on [1].
[1]: https://github.com/swaywm/wlroots/pull/2315
|
| |
|
|
|
| |
Split cmd_exec_always into separate methods for general validation and
process creation. This fixes a potential call of join_args with 0 arguments.
|
| |
|
|
| |
Gracefully exit on SIGINT, like we do for SIGTERM.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
If the environment variable is not defined, getenv returns NULL.
Passing a NULL pointer to the "%s" format specifier is undefined
behavior. Even if some implementations output "(null)", an empty
string is nicer.
|
| |
|
|
|
|
| |
`!*rgba` tests if the first byte of rgba isn't `'\0'`.
`hex_to_rgba_hex` returns NULL if `parse_color` fails. There's a null
pointer dereference in that case. The intended behavior is `!rgba`.
|
| |
|
|
|
|
| |
The pointer `data` is cast to a more strictly aligned pointer type. To
prevent issues, the `data32` buffer is removed and its occurrences are
replaced with an offset from the `data` buffer.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the mouse/cursor/pointer is near the edge of an output when a "move
position to pointer" command is run, then the floating container will be
constrained to fit inside the bounds of the output as much as possible.
This behavior matches what i3 does in this scenario. I also think it is
a better user experience.
Relates to #4906
The logic for the bounds check follows the implementation in i3: https://github.com/i3/i3/blob/733077822302d8b77eacb606a26fd002a42f534f/src/floating.c#L536
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Usually it should be enough to simply not grant a client's
minimize request, however some applications (Steam, fullscreen
games in Wine) don't wait for the compositor and minimize anyway,
getting them stuck in an unrecoverable state.
Restoring them immediately lead to heavy flickering when unfocused
on my test application (Earth Defense Force 5 via Steam), so it's
preferable to grant their request without actually minimizing and
then restoring them once they are in focus again.
|
| | |
|
| | |
|
Tamir Zahavi-Brunner
mwenzkowski
Dimitris Triantafyllidis
Ronan Pigott
Daniel De Graaf
Tudor Brindus
Tarmack
Tobias Langendorf
David96
John Mako
Rouven Czerwinski
Geoffrey Casper
BrassyPanache
Brian Ashworth
Simon Ser
Konstantin Pospelov
Rex Hackbro
Antonin Décimo
Thayne McCombs
Nils Schulte