Age | Commit message (Collapse) | Author |
|
|
|
Fix #587
|
|
|
|
|
|
Plug two memory leaks introduced in the border drawing code.
|
|
When creating a new view, wlc usually returns an initial geometry with
size 1x1. Setting those values as desired width/height causes a problem
for some windows (QT5) because they don't request a new geometry for
instance when made floating, so the floating window becomes 1x1.
To fix this problem we can just omit setting the desired width/height on
new_view and instead let the clients request a certain size if they feel
like it. e.i. gnome-calculator.
Fix #578
|
|
|
|
|
|
|
|
This fixes floating borders when moving outside of the output. Not sure what
happens with dual screen as I only have 1 monitor
|
|
|
|
|
|
Fix #564
|
|
|
|
Makes it possible to set default layout style for new windows and new
floating windows.
Close #556
|
|
|
|
|
|
|
|
|
|
I made this configurable but I didn't make the command for it. That's
left as an exercise to an eager contributor.
mod_scroll_behavior [gaps inner|gaps outer]
Would merge implementions of more behaviors for mod+scroll, if anyone
has some neato ideas.
|
|
Implement Window borders
|
|
This makes it possible to define a mode name with surrounding spaces if
so desired. e.g.:
mode " hello " { }
|
|
|
|
|
|
|
|
|
|
The borders are implemented as a surface/buffer attached to each view
which is sent to and rendered by wlc in the view_pre_render callback.
All the drawing logic is handled in sway/border.c and all the logic for
calculating the geometry of the border/view is handled in
`update_geometry` in sway/layout.c (same place as gaps are calculated).
|
|
|
|
|
|
|
|
|
|
Note that this segfaults ALL THE TIME in wlc code. Paging @Cloudef for
help, I'm at a loss.
|
|
|
|
Please don't complain to me about the performance of this
|
|
Closes #531
|
|
|
|
|
|
|
|
|
|
|
|
The include command (`include <path>`) makes it possible to include sub
config files from the main config file (or from within other sub config
files).
The include command uses the following rules for including config files:
* the `path` can be either a full path or a path that is relative to the
parent config. Shell expansion is supported, so it's possible to do
`include ~/.config/sway.d/*`.
* The same config file can only be included once (to prevent include
cycles). If a config is included multiple times it will just be
ignored after it has been included once.
* Including a sub config file is the same as inserting the content of
that file into the parent config, thus rules about overwriting
bindsyms etc. works the same as for a single config.
Implement #542
|
|
This makes sure that sway will gracefully exit if the config is not
found or sway is unable to read it.
|
|
|
|
|
|
|
|
Use correct type for keycode
|
|
|
|
|
|
Sway has been very strict when it comes to key handling. Only on an
exact match would a bindsym be triggered.
This patch makes it less strict by for instance allowing the key combo
`$mod+1+2` to act as `$mod+2` if 2 was the last pressed key and `$mod+1`
if 1 was the last pressed key.
The new key handling uses the following algorithm:
1. List of bindings sorted by number of keys in binding (already the
default)
2. Find all bindings covered by the current keyboard state and list them
by same order as in 1.
3. Select the first binding from the list where the last pressed key is
part of the binding.
Addresses #452
|
|
|