Allow toggling the layout before selecting a different one #27
No reviewers
Labels
No labels
A: maintenance
A: question
B: not applicable
B: not reproducible
B: resolved
C: multi-DPI
C: protocols
C: rendering
C: XWayland
Kind/Bug
Kind/Feature
Reviewed
Duplicate
Reviewed
Won't Fix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
dwl/dwl!27
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "guidocella/toggle-layout-immediately"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I don't think I'm feeling this one for mainline dwl. If you haven't changed the layout yet, I think it makes sense that there's not a previous layout. Plus it adds a non-obvious line of code for a case that will happen at most once per monitor, and it's easy enough to switch the layout explicitly the first time.
When it creates a monitor dwm explicitly sets the previous layout to the second one to allow this
I personally find this convenient and only switch layouts by toggling between tile and monocle (which I made 2nd in layouts array), without having to remember if I already switched, and never use the key bindings to select a specific layout.
The line can be made clearer by making it longer, for example
or just assume the common case that the monitor's first layout is &layouts[0] and do like dwm
Anyway, your call.
This is a valid use case for me: I expect dwm to toggle between the first two layouts (monocle, tile) when it first starts up.
Further to that, I'm using the pertag patch, and don't want to have to manually setup the toggle state for every tag.
Hm. It's not the job of the core codebase to support an external patch like pertag - that responsibility belongs to the patch. On the other hand, parity with dwm is a legitimate point. dwm doesn't support setting the initial layout like dwl, and I'm trying to discern what is the least surprising behavior given that difference.
I'll leave the issue open for now since I don't feel it's 100% resolved, but I went ahead and linked this patch on the new user-contributed patches page. If you don't want it there, you can feel free to take it down.
I think this is a valid pull request, dwm does this. If the goal is for dwl to have feature parity with dwm, then this should be merged.
@sevz maybe it's time to revisit this since parity with
dwmis going to be priority in a few days?@pm4rcin "since parity with dwm is going to be priority in a few days" <- What does this reference?
Probably it doesn't make sense in this context because it adds at most 1 SLOC. I referenced the PR that drops SLOC limit.
Pull request closed