-
-
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
Handle scratchpad windows #35
Comments
Thanks, I'll look into this. I don't use scratchpads myself so I hadn't really thought about it before. |
Okay so saving whatever's in the scratchpad is no problem, it should work exactly the same as with any other workspace. But restoring them is more of a challenge. The issue is that as far as I know there is no way to actually switch to the scratchpad workspace. The restoring of programs and workspaces relies on you actually having that workspace open and focused. So the best solution I can think of right now is to:
Does this sound like it would work for your use case? |
That sounds like it would work perfectly, thanks! Or it might be fine to skip steps 1 and 4, just stay on the current workspace, create each window (with the correct geometry) and move it to the scratchpad? I have config rules that already move some of the windows in question to the scratchpad, but I don't think there's any adverse or back-and-forth effect if you move a window to scratchpad twice. |
Actually it seems like i3-resurrect works fine with the scratchpad already. Try doing |
When I do that, it creates the two JSON files but each one is empty except for []. |
Oh, yes I see in the current version that is the case. I was testing on the development branch (next). It's because I've added support for floating windows, and all scratchpad windows are floating, so it would never have worked in 1.3.2. Seeing as it works on the development branch, that's pretty much everything that I wanted to do for the next release, so expect 1.4.0 to drop soon. |
Oddly, I just tested i3-resurrect save on a normal workspace and it does the same thing there. I have used it successfully recently though. |
Just built the next branch and it also produces the 2-byte |
That sounds strange, can you give the output of If you're running what's on the next branch then the layout file definitely shouldn't contain EDIT: |
You're right, it's
|
And you get no errors on the command line when you run the command? Are you running it from the command line or through a keybinding? How did you install it? Also might be helpful to know what distro you're on. Also please provide the full command you are using and the full path to the file you are checking the contents of afterwards. It seems strange that this would happen when it works fine in the Travis build, and works for me locally, and works on a VM I tested it on. |
Well, this morning I had a hardware crash and now after rebooting, saving scratchpads works better! It populates the JSON files fully. Restoring is not working perfectly though. Two issues:
|
Are these restoring issues only with the scratchpad? Also would be helpful to see the screenshot of the whole desktop, and maybe show what the actual name/class/title of the chrome window are. |
Yes, only with scratchpad as far as I can tell, but I haven't done a lot of testing with other floating windows. Here's a screenshot of the whole desktop: https://i.imgur.com/kujEzjc.png According to xprop, when the Chrome window is correctly loaded:
|
Okay so I've been testing with google chrome a bit just now and it mostly works. I found there was a problem where for some reason the Chrome process cmdline array has a bunch of empty strings and i3-resurrect wasn't handling those well so chrome didn't get launched. I've fixed that now and will push the changes in a bit. Aside from that, if the restored program windows are not swallowed into the placeholders created on the scratchpad upon their initial creation, they will appear on the current workspace and not the scratchpad (because it is the placeholder containers that have the scratchpad_state property which causes them to appear on the scratchpad). If this happens, you can move those windows to the scratchpad manually and run I also notice that the window instance is different on your system. I am on Arch Linux and the instance name of the chrome window does not change depending on the page for me. This is what I get for the same page:
Because the instance name seems to change depending on the page you're on, this may be causing it to not be swallowed without triggering a deferred swallow (as I have just described how to do). I figure maybe for your scratchpad windows you don't need such precise layout restoring, and class + instance isn't really much better than just class. So you could just do |
Pulled the latest from the next branch and tried with and without |
Are you sure the programs themselves are actually being started? |
They're definitely not being started. |
So what's in the programs file? |
Pasted below, and it looks like the ones that fail to launch are the ones with command line flags! I deleted
|
Oh did you edit the programs file manually? Here I explain what's going on here: #50 (comment) |
No I didn't -- will I need to edit the JSON files every time I save a workspace? That sort of diminishes the convenience of i3-resurrect. |
No, you shouldn't have to. It's weird that it's saving multiple arguments as one... How exactly did you launch those programs the first time? |
I use Rofi to call
Similar for the Chrome apps. |
So far I'm unable to replicate this at all. I launch programs using rofi as well and the cmdline never has multiple arguments in one list element. What distro are you using? EDIT: also what's in your i3-resurrect config file? |
Ubuntu 18.04. I just tried manually running The i3-resurrect config looks like this:
|
Ok looks like this was an upstream bug in psutil giampaolo/psutil#1179 They partially fixed it by checking if there was a null byte at the end of the cmdline file and if there is not they use space as the separator. However it looks like some processes terminate the cmdline file with a null byte but use spaces as a separator, which is very annoying.. I shall probably create a workaround with shlex.split() or similar. Do you think you could check the contents of the cmdline files for the processes you're having trouble with? You can do this like so:
|
Interesting.
|
Yeah that's exactly it then, it's NUL terminated but uses space for separators, which I think means the process is modifying its own cmdline (by modifying Not much point waiting for psutil to work around this so I'll work around it with |
Closing this as scratchpad windows are supported in the latest release and the issue you are having now is #55 |
It would be great to be able to treat all the running scratchpads as a workspace that can be saved and restored like the others. I often have a dozen of them going.
The text was updated successfully, but these errors were encountered: