-
-
Notifications
You must be signed in to change notification settings - Fork 18
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
Question: does this handle wrapping workspace layouts with a new container? #33
Comments
You are right, I had overlooked this because I never do that, I always start with one window then create a new split container so I wouldn't lose any layout information. I've tested changing the workspace layout itself and yeah that information is lost. Not sure why they made it like that but it should be an easy fix as long as Out of interest, has this affected you when using i3-resurrect? I wonder how many people actually change the workspace layout instead of creating a new split container. And thanks for the report 😄 |
I think I ran into an issue because of this where the layout wasn't restored correctly, but I'm not sure if this was actually the cause. |
Ah, yeah that would do it. I'll try and get this sorted as soon as I have time. |
Awesome, thanks! |
Hm, I'm trying to implement this now and it's proving to be less trivial than I'd hoped. I can include the whole workspace node, but when you restore it, it creates a new workspace with the same name and leaves the old one in the tree. And even though the old workspace is empty it doesn't go away because an invisible container gets left behind. The original workspace name in my test was "10", and the new ones that are created with the name "10" displace the existing workspace with the same name, so the old workspace 10 gets automatically renamed to "10_1", "10_2", etc. Each of these workspaces has "num": 10, but their names are different. I also tried it without saving any of the workspace's attributes (apart from nodes), but the new containers it creates are a whole two levels deeper in the tree than the original windows, and placeholder containers are not created, but instead it creates invisible containers. All in all it doesn't look like this is going to work. I can see why it's done this way now, because it's much simpler to just be able to insert a list of new containers into a workspace and have windows swallowed into those rather than trying to selectively overwrite and merge parts of the tree (if you could overwrite the whole workspace tree I'm not sure what would happen to existing windows). |
Thanks for working on this! |
Well, I can reproduce the issue by:
But this is not something I ever do in practice, personally. You can avoid the issue by just creating an empty container inside the workspace then changing the layout of that, rather than changing the layout of the workspace itself. This is what I would recommend everyone to do, seeing as |
Just looking at i3's code to make sure I understand how it works.
So it checks for the type of the data it loads from the file whose path you pass If the content is of type "workspace", it appends the layout to the currently This confirms what I thought. It cannot overwrite nodes, it's very simple and At least I've learned something useful from this. I think it wouldn't be too |
How do you create an empty container? |
Re-reading this, I think my specific use case actually won't be affected from the issue you see: I only restore workspaces after I reboot, so none of my previously saved workspaces exist at this point. |
No because it's the layout restoring stage which comes after you restore programs, so you would've presumably already opened those workspaces to restore the programs on them. Either way if I change the way the layout is saved/restored so that it inserts workspace nodes this will break it in situations where it the workspace does exist. For most people it would introduce confusing inconsistencies or even straight up buggy behaviour. |
Hm okay I guess you can't do this, I thought it was possible.. |
Ok what might work is if I get it to to use the command EDIT:
And it seems to work perfectly so far with no significant performance impact 😃 |
Previously the layout mode/direction of the root workspace node was not saved/restored. Now this is done by saving the whole workspace tree (instead of just the children of the workspace node) and when the layout is restored the root workspace node is set correctly and the child nodes are extracted into a temporary file so that they can be passed to append_layout on their own. Closes #33
I actually don't restore the programs/windows using i3-resurrect (because I don't think it's possible to do it correctly in my case), only the workspaces. Specifically after I reboot and start my user graphical session I do the following:
Yup. |
Nice, that's a very good way to use it 😃 I do a similar thing for browser windows Anyways, fix for this issue is done and will be available in the next release along with some other bug fixes, extra features, and very significant performance improvements! By the way if you ever want to try out unreleased changes, the "next" branch is the main development branch and you can clone it and install it with pip. I only merge into the master branch for releases, because the AUR package is a source package but I only want it to be updated when I create a new release. |
According to i3-save-layout's docs, the base workspace layout is not saved, only that of its children (not sure why this is the behavior).
Does i3-resurrect handle it automatically?
Thanks!
The text was updated successfully, but these errors were encountered: