-
-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Per-output layout settings #401
Comments
Part of issue YaLTeR#401 Per-output layout settings. Creating new types for the Output layouts because it makes handling the layout overriding much simpler down stream by allowing us to just ignore fields with None instead of writing some custom solution to detect which fields are/ aren't set by the user since the regular Layout struct hierarchy has set deafaults for all sub fields in the hierarchy. Small downside of Layout and OutputLayout not being 100% in sync but I think the trade off is worth it especially considering there are some fairly deeply nested fields that make no real sense being set on a per output basis that we can just ignore for output specific layouts.
part of issue YaLTeR#401. My idea would be to have a hashmap of layouts keyed by the output name. Downside is that we're essentially creating clones of the base layout for every output with configuration deviations but I would assume there aren't so many that there would be an issue with this. We can then have a simple layout getter that gets either the base layout or output specific layout if there are deviations from the base.
Love the project and I'm looking forward to it getting to the point I can replace Hvprland with this. I've begun work on this feature in a way that slightly deviates from the original idea in your description of the issue. Any feedback on the approach so far? I haven't had the chance to use Rust in a 'real' project before. All the tangible work I've done so far is present in the 2 commits above that reference this issue. I will continue adding a reference to all my commits when I get around to progressing this issue. |
Hey,
I suspect we may need to do the Option refactor either way for the ability to split a config into separate files. Might be worth looking into refactoring the Layout config itself to use Options. Similar to how window rules work, together with ResolvedWindowRules. |
Check if there are layout overrides available for current monitor and use those as options instead. issue YaLTeR#401
I'll have a look if I can reasonably fit the refactor into this feature. I suspect there might be enough work involved that it could be worth being a separate issue from this one or as a part of the multi file config issue. |
It is sometimes useful to change some layout properties per output. For example, one might want a smaller default column width on a bigger monitor. Or always-centering mode restricted to a particular output (#381).
The obvious way to represent it in the config is to just add the
layout
section to the outputs:niri-config
-wise, we need to implement merging for thelayout
structs (similar to window rules vs. resolved window rules), which will also be useful in the future for configinclude
. Also, some way to deny theon
flag in the globallayout
section without duplicating all of the structures involved.The text was updated successfully, but these errors were encountered: