This fixes a bug where the key at index 0 in the `key_state_array` would
be overwritten by the next pressed key. This broke any bindings
consisting of multiple non-mod keys like: `$mod+a+b`.
If the width or height of a container can't be evenly distributed to its
children, then the layout algorithm still thought it got it right (due
to using decimals) which caused a gap of one or more pixels for some
window arrangements.
This is fixed by this patch by first rounding off the width and height
(so that decimals are never introduced) and then adjusting the last
view in a container to fill the remaining pixels (which now is counted
correctly due to the decimals being removed).
Also, due to the way gaps are implemented, an odd sized gap can never be
aligned properly, so just adjust to closest even number.
I've tried to make as few changes, as possible.
Usually the reason for using qsort_r is, that you can pass an extra userdata pointer to the
compare function. However, in sway list_sort wrapped qsort_r and always called a wrapper
function for comparing, the wrapper function then had the real compare function as argument.
The only thing, that the wrapper function does, is dereferencing the 'left' and 'right' function
arguments before passing them to the real compare function.
I have renamed list_sort to list_qsort to avoid confusion (so nobody tries to use list_qsort like
list_sort) and removed the wrapper functionality. Now the dereferencing must be done in the
compare function, that gets passed.
Some compare functions were used in both list_sort and list_seq_find. To make the difference
clear, I've added a '_qsort' suffix to the compare functions, that are intended to be used with
the new list_qsort. (In other words: list_qsort is not compatible anymore with list_seq_find).
- Changed and renamed function (it isn't used anywhere but in commands.c, and only for sorting):
compare_set -> compare_set_qsort
- New wrapper functions:
sway_binding_cmp_qsort (for sway_binding_cmp)
sway_mouse_binding_cmp_qsort (for sway_mouse_binding_cmp)
Our initial implementation of `bar { }` assumed that the commands could
only be used in the config. This is not true for two commands:
* bar mode
* bar hidden_state
This patch makes it possible to issue these commands outside a bar
block, for instance through swaymsg
$ swaymsg bar mode hide bar-0
This does not implement the `barconfig_update` IPC event which should be
trigged from these commands. I have added TODO's where this should be
added once implemented.
Track each panel separately via its wl_resource. `set_panel_position`
might be called before `set_panel`, so reuse panel config.
Place the position in panel_config so that each panel has its own
position.
This works by tracking the pids of the child processes in the related
output container and terminating the processes and spawning new ones on
a config reload.
Should solve: #347
If the output is not at the correct size then that info must be queried
from wlc. The output size is used by e.g. seamless mouse to detect
output edges.
With this patch the output size is now correct and the workspace size is
adjusted according to any panels.
Without this patch seamless mouse would fail to detect outputs
above/below each other if there was a panel in between because the
output would offically end where the panel started, not at the actual
screen edge.
fixes#308
Ordered by number ascending, with insert before same numbers.
Workspaces without numbers are appended at the end of the list.
Example order:
1 2:named 3:the_second 3:the_first 9 FIRST_NAME SECOND_NAME ...
If the id is defined by another bar it will just use the default id for
the bar. Typically `bar-x`.
If the id command is used multiple times within a bar block, the last
one will 'win'.
If focus would move in an output with a fullscreen view, it always
leaves the output. If focus would enter an output with a fullscreen
view, it always focuses the fullscreened view.
CMake takes a `FALLBACK_CONFIG_DIR` flag which is the directory where the
standard configuration file `config` is copied at installation.
If loading from typical configuration directories fails, sway loads
FALLBACK_CONFIG_DIR/config (/etc/sway/config by default).
When turning a float to a non-float, `get_focused_container` might
return another floating view, causing the active view to be inserted
into the floating list on its workspace instead of the normal child list
which it should. (Since it has `is_floating` as false the resulting
discrepency triggered other bad behaviour eventually leading sway to
crash.)
This patch fixes that by simply checking floating status before making
it a sibling.
Using 'flag' results in duplicate code paths for short and long options.
This broke the -q short option in swaymsg, because there was:
{"quiet", no_argument, &quiet, 'q'}
Which will set quiet to 'q' and return 0, not 'q'.
First of all because it's not needed that early, and second of all
because there's a bug where calling `sway --get-socketpath` via `popen`
causes the child sway process to spin/hang instead of returning EOF.
(Specifically `(unset SWAYSOCK; swaymsg)` hangs.) This patch fixes that.
(Also note that this patch moves the "detailed review" comment, so I
guess this patch requires extra detailed review?)
This function looks for bound commands that start with `workspace` (ie.
the commands that change to a static workspace) and fetches the
workspace name.
However, if it's actually a list of commands, then the parsing will pick
up the delimiter ("," or ";") and also fail to recognize keywords
("next" etc).
This patch fixes that by properly separating with delimiters.
This makes escaping the arguments obsolete.
Also avoid dynamic memory allocation for the output id. It only supported ids up
to 99. Now we support up to 999, and take 4 bytes off the stack instead.
A criteria is a string in the form of `[class="regex.*" title="str"]`.
It is stored in a struct with a list of *tokens* which is a
attribute/value pair (stored as a `crit_token` struct). Most tokens will
also have a precompiled regex stored that will be used during criteria
matching.
for_window command: When a new view is created its metadata is tested
against all stored criteria, and if a match is found the associated
command list is executed.
Unfortunately some metadata is not available in sway at the moment
(specifically `instance`, `window_role` and `urgent`). Any criteria
string that tries to match an unsupported attribute will fail.
(Note that while the criteria code can be used to parse any criteria
string it is currently only used by the `for_window` command.)
This fixes a compiler warning:
../sway/extensions.c: In function ‘set_background’:
../sway/extensions.c:16:37: warning: implicit declaration of function ‘malloc’ [-Wimplicit-function-declaration]
struct background_config *config = malloc(sizeof(struct background_config));
^
../sway/extensions.c:16:37: warning: incompatible implicit declaration of built-in function ‘malloc’
../sway/extensions.c:16:37: note: include ‘<stdlib.h>’ or provide a declaration of ‘malloc’
We can't handle them currently (the criteria needs to e.g. be passed to
each command handler which then needs to do the right thing), so it's
better to just do nothing than to create unexpected results (because the
command was executed on the wrong view).
(Before this patch any command list with a criteria string would simply
fail to parse, so this is at least a step in the right direction.)
This also fixes a bug where issuing a new "workspace a output b" command
for an already assigned workspace would not work (the old config would
be found first and used instead).
This does not work as expected. I think the problem is on the wlc side.
Please review, @Cloudef. To reproduce the issues:
1. Run sway
2. Open terminal in sway
3. Run swaybg
swaybg will create a surface and ask to have it set as the background,
but wlc_handle_from_wl_surface_resource will return 0. If the swaybg
surface is a shell surface, then it works - but wlc complains about the
pointer type and segfaults as soon as the pre-render hook tries to draw
the background.
When querying for an adjacent output we now need an absolute position in
order to know which adjacent output that matches. (The position is
either the current mouse position or the center of the currently focused
container, depending on context.)
If two outputs have one edge each that at least partially align with
each other they now count as adjacent.
Seamless mouse is affected by this and now properly moves and positions
itself between outputs with "uneven" placement (as long as they have at
least some part of the edge adjacent to each other).
When focusing or moving a container in a specified direction the center
of the current focused container decides where to look for an adjacent
output. So if e.g. an output has two adjacent outputs to the right and a
"focus right" command is issued then it's the placement of the currently
focused container that decides which output actually gets focused.
Also, if an output has at least one output adjacent in some direction
but the entire edge is not covered (ie. it has "holes" with no outputs),
then the algorithm will choose the output that is closest to the
currently focused container (this does not apply to seamless mouse, the
pointer will just stop at the edge in that case).
Mikkel Oscar Lyderik
crondog
Drew DeVault
S. Christoffer Eliesen
Yacine Hmito
robotanarchy
progandy
Streetwalrus Einstein
Drew DeVault
Kevin Hamacher
Christoph Gysin
taiyu