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).
Christoph Gysin
S. Christoffer Eliesen
Drew DeVault
taiyu