Ensure that sway workspaces are always displayed in the same order as
used internally by sway. The previous sorting code always sorted
unnumbered workspaces lexicographically. This isn't the order used by
sway internally. Therefore, commands such as "workspace next" might have
jumped arbitrarily in waybar.
This commit reworks the sorting code such that the internal order is
always obeyed. Additionally, numbered persistent workspaces are inserted
at their natural position at the front of the workspace list while
unnumbered ones are appended. This should match the expectations of
workspace ordering known from sway's behavior.
The changes make the configuration property "numeric-first" unnecessary
as this will always be the case now. There's also no reasonable way
around this behavior now. Otherwise, persistent workspaces would jump
around in the visual representation as soon as they become known to
sway.
Fixes#802
The logind feature adds a new inhibitor module which allows to acquire
the inhibitor locks that logind presents.
Signed-off-by: Alexis Cellier <kernelserror@gmail.com>
There is a double delete situation which causes a SIGSEGV to happen
during destruction of bar.
This was introduced by the group feature patch.
The same object pointer is stored in two different vectors of
unique_ptr<AModule> element. Replace with shared_ptr to handle
reference counting correctly and avoid double delete.
Allow changing existing modes and adding new ones via `modes`
configuration key.
`modes` accepts a JSON object roughly described by the following type
```typescript
type BarMode = {
layer: 'bottom' | 'top' | 'overlay';
exclusive: bool;
passthrough: bool;
visible: bool;
};
type BarModeList = {
[name: string]: BarMode;
};
```
and will be merged with the default modes defined in `bar.cpp`.
Note that with absence of other ways to set mode, only those defined in
the `sway-bar(5)`[1] documentation could be used right now.
[1]: https://github.com/swaywm/sway/blob/master/sway/sway-bar.5.scd
If the primary output does not support changing volume MPD will report
-1. Ensure that negative volume levels will be represented as 0 instead.
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
I was seeing "[warning] Requested height: 20 exceeds the minimum height: 30 required..."
Lines 114-134 are relevant; 133 overrides the requested height with the minimum height when GTK wants more pixels to work with. So, the code is behaving as expected, and "less than" matches the code's logic.
Aleksei Bavshin
Johannes Wienke
Alex
ilkecan
bd-g
Brent George
aashu
Alexis Cellier
John Fredriksson
Patrick Nicolas
dmitry
Nicolas Joyard
kraftwerk28
Sefa Eyeoglu
Mohammad Amin Sameti
Marwin Glaser
jonbakke