Fix#444
This is a temporary fix, the real fix is to store the commands as a
formatted argv array, so they don't have to be reformatted all over the
place.
This is a "simple" version of --release (same as i3) that only supports
a binding that contain one normal key. e.g.:
bindsym --release $mod+x exec somthing-fun
I didn't bother implementing it for a combination like `$mod+x+z` since
it is a bit tricky to get right and also a bit weird to actually do on a
keyboard.
This makes sure that a modifier event is only sent for active bar
modifiers, and that it is only sent once for each of those modifiers.
An active bar modifier is a modifier defined for a bar with `mode hide`
and `hidden_state hide`.
Detects when a bar modifier key is pressed/released and sends a modifier
IPC event to any listeners (usually swaybars).
This way a swaybar can listen on the modifier event and hide/show the
bar accordingly (not implemented yet)
The modifier event looks like this:
{
"change": "pressed", // or released
"modifier": "Mod4"
}
This fixes https://github.com/SirCmpwn/sway/issues/431 by returning
focus to the fullscreen view. Also it fixes the issue with the
fullscreen view pointer not being set which did my head in
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.
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 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'.
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.
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.
