I want to implement more functionality to the bar, similar to what
machi has in its bar, but it seems a lot easier to just handle the bar
with the rest of the manage/render loop that rwm and beansprout use.
To do that, I had to convert the bar to use river-shell-surface instead
of zwlr-layer-shell.
In that process, I also removed support for zwlr-layer-shell exclusive
zones. It made calculating the usable area for the layout more annoying.
If someone *really* wants, I would consider adding it back, but the only
thing I can think of that requires exclusive area is a bar, and we don't
really support other bars, so I don't think it's needed.
I also switched a couple of places to use saturating subtraction on
unsigned ints.
This adds a new config `primary_side` that can be either `left` or `right`
and determines whether the primary stack is on the left or the right
side of the screen.
This is a new config option that allows the user to set the width ratio
when only a single window is tiled and visible. The main idea is that,
on ultrawides, a single window taking the full width could be ugly.
With this new config, you can make the window take a smaller width.
I also renamed consts to snake_case instead of SCREAMING_CASE and fixed
a bug where the default primary_count and primary_ratio weren't updated
on config reload.
When I added support for propose dimensions, I was foolishly just
choosing the min (or max) if only one was set. However, a lot of windows
will a set a very small min size with no max, which meant we would have
really tiny windows when first floating one. The fix was to try set to
75% but then clamp to the min/max dimensions the window gave.
After fixing that, there was still an issue where windows kept their
size after being floated. That's because there was a propose_dimensions
call happening later in Window.manage(). I'm skipping that now if a
window became floating in the same manage event.
This moves window initialization earlier in the manage sequence.
Previously, it was on the Window's first manage() call, but this is
after the layout has already been calculated, which matters both because
of tags and whether the window starts floating or not.
Now, initialization is handled in a separate function that gets called
in Output.calculatePrimaryStackLayout() instead.
Also fixed a crash that I'm really not sure how I didn't have happen
before during Output.create()
Right now, only Window is updated to use Rect. I'll try updating all
instances of x,y,width,height combo to use it.
This adds a few new options for the bar (instead of hardcoding all of
them). fonts, text_color, background_color, positoon, and margins.
Also fixed a couple of bugs when reloading the config and destroying
layer shell and wl surfaces in the wrong order.
We had to fix a couple of compile errors that weren't showing while it
wasn't wired up (since I never just tried to compile TagOverlay.zig on
its own). We also changed the lifecycle to re-create/destroy the surface
to show/hide it, similar to the way that river-tag-overlay actually did
it.
Finally, I added @branchHint(.cold) to a few places in the event loop
where, if we're in the branch, the wm is definitely exiting, so it's
fine if they're cold (should almost never happen).
Now, I actually save the river-layer-shell-v1 and keep track of the
non-exclusive area. The layout calculation uses the usable area instead
of the entire output's geometry.
I removed boundary clamping for the floating windows because it was a
bit janky when hitting the edges. I'll probably add it back at some
point. I also made windows default to 75% of the usable area instead of
keeping their tiled size so that maximized windows look decent when
floating for the first time. Finally, since I removed the clamping, I
added a center_float keybind to center a floating window. If you're
cycling through focused windows and one isn't on the screen, you can use
the center_float bind to get the window visible again.
Replaced all divTrunc with divFloor to be consistent. I think they
should all be positive, anyways, so they'd be the same, but I like just
having one.
By default, each tag mask will use the default count and ratio. If the
mask gets modified by any of the commands, it gets added to a hash map.
When changing tag masks, the current count and ratio are stored, and
they're used again later if you switch back to that mask.
This commit also adds primary_count and primary_ratio to the general
settings for the config, so users can set a default count/ratio to use.
