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.)
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).
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).
When yes, the old behaviour of adding half the inner gap around each
view is used.
When no, don't add any gap when an edge of the view aligns with the
workspace. The result is inner gap only between views, not against the
workspace edge.
The algorithm is not perfect because it means the extra space is
distributed amongst edge-aligned views only, but it's simple, looks good
and it works.
Place mouse at center of focused view when changing to a workspace on a
different output, if option is enabled. (This replicates existing i3
option.)
This can be triggered in multiple ways:
A) via `workspace <name>` which changes output
B) via `focus <direction>` which changes output
C) via `focus output <name>` which (obviously) changes output
Replicates i3 option. Verbosity level given as command line argument
becomes default log level, and using 'debuglog toggle' switches back and
forth between default and debug (or L_ERROR and debug if default is also
L_DEBUG).
This is an undocumented feature (the word "number" is just ignored
anyway), but it exists to be compatible with i3 config syntax.
Plus some code cleanup at the same time.
In i3 the ipc reply will contain a human readable error message, and
this patch replicates that behaviour.
However, that error message is also useful for logging, which this
patch takes advantage of.
E.g. instead of logging errors directly in commands.c/checkargs, it is
fed back to the caller which eventually ends up logging everything with
maximum context available (config.c/read_config).
So instead of logging e.g. "Error on line 'exit'" it will now log:
"Error on line 'exit': Can't execute from config."
Before this patch sway would proceed into find_handler which would cause
a crash trying to parse a NULL string.
This could be triggered via e.g. `i3-msg -s $(sway --get-socketpath)`.
When using an i3 config verbatim in sway this switch to exec or
exec_always might appear.
Before this patch the switch would be passed to /bin/sh, causing
an error, and the command would not be run.
