Open alexozer opened 6 years ago
Hi @alexozer, glad to hear you're enjoying the project and apologies for such a late response.
I think this is a great idea - in fact, the lack of a feature like this is something I too struggle with every day. It's annoying when trying to open programs like Steam or Slack where the brief teardown/reopen of windows causes the desktop to get removed.
I think this behavior can be achieved pretty easily by adding an option to prevent the removal of the focused desktop, even if it's empty. Will this accomplish what you're asking for?
I think that would solve the problem, yes.
I hope this feature will be implemented. A lot of apps like to create windows and close them after the loading screen. When the last window is closed, it jumps to the next occupied desktop and spawns the actual app window. It's really annoying. Other than that, I love using btops with bspwm.
Check out #3
Hey all, apologies for dragging my feet on this one. Thanks for the pull request @MyNameIsCosmo, i'll be testing that out this weekend.
I've been toying with some more ideas around adding config options to support loading certain apps in the background, I think that could also be a nice alternative if you still want desktops to get removed on window close.
Will hopefully start experimenting with that this weekend as well
All good, we all get busy. I've been using btops with one minimal issue (see #4) unrelated to my patch, and so far everything works well.
One adverse effect I've noticed from the patch in #3 is that if you set min = 1
in your btops/config.toml
, btops will keep the focused empty desktop open, and when switching to the "next" empty desktop, it will delete one of them, resulting in the 1 desktop left, i.e. "1 2" > "1 2" > "1'
I think the proper behavior for this effect should be to remove the empty and not focused desktop if the current focused desktop is empty, going from "1 2" > "1".
I'll push another commit to account for the above behavior.
On another note, please do open some more issues with features you have in mind. I wanted to help document the code a bit so it would be easier for new contributors to open PRs.
I don't want to be annoying, so I tried waiting a few months first. Can we get an update if this is still being worked on? Pretty much the only thing I'd like to see for btops. Everything else works great.
Hey @gavsiu, I'm still here and yup it's still being worked on. @MyNameIsCosmo has a nice working change for this feature here: https://github.com/cmschuetz/btops/pull/3 and hopefully we can get this in soon
Also, let me know what you think of https://github.com/cmschuetz/btops/issues/7. Does anyone else experience similar pain with certain applications?
Hey @gavsiu, I'm still here and yup it's still being worked on. @MyNameIsCosmo has a nice working change for this feature here: #3 and hopefully we can get this in soon
I did saw that, but I didn't want to replace your btops installation with his in case you updated yours unless there's a way to merge his changes temporarily (I'm not that familiar with git).
Also, let me know what you think of #7. Does anyone else experience similar pain with certain applications?
Yes. This is also one of the reasons why I wanted #1. It would be nice if I didn't have to wait for the application to open before switching off to a different desktop, but I didn't think of that. Off the top of my head, other than Steam that was mentioned, it happens with LibreOffice, KeePass and maybe some others.
You can have a local btops built from my fork with the feature. Your feedback could help find bugs and implement some use cases that might be missed otherwise, which could help merging the changes to master quicker.
If there are any changes for this repo, I'd be happy to do a git rebase with the changes on top of the btops master.
You can have a local btops built from my fork with the feature. Your feedback could help find bugs and implement some use cases that might be missed otherwise, which could help merging the changes to master quicker.
If there are any changes for this repo, I'd be happy to do a git rebase with the changes on top of the btops master.
Almost 2 years later, I still wish this got fixed. I finally got off my lazy butt and tried your fork, but had issues.
remove-empty = true
remove-focused = true
append-when-occupied = true
renamers = ["classified", "client", "constant"]
With this config, nothing changed. I'm guessing remove-empty was the problem.
remove-empty = false
remove-focused = true
append-when-occupied = true
renamers = ["classified", "client", "constant"]
With this config, lets say I have a window open on desktop 1, I switch to the only empty desktop 2 and open a window. It now appends an empty desktop 3. I close the window in desktop 2 and am still left with 3 desktops, 2 empty.
remove-empty = false
remove-focused = true
append-when-occupied = false
renamers = ["classified", "client", "constant"]
That was dumb. No empty desktops to switch to.
What config is supposed to work?
Any updates on this? I really like btops and it's what makes me want to use bspwm, but this annoying behavior is making me want to stop using it.
So, I forked @MyNameIsCosmo's fork and applied the fixes proposed by @cmschuetz on #3, add the use of Go module and improve the desktop removing when the focused desktop is the second to last one.
I PR into the main repository, but in the meanwhile, if someone stumble upon this, you may build the application from my . If it doesn't get merged, I will also add it to the AUR.
First of all, thanks for making a tool like this, I've been looking for something like this forever.
So when a desktop becomes empty, btops currently switches to another desktop. However, it might be nice if btops had an option to remain on the empty desktop and not remove it until it is switched away from (kind of like Gnome 3). This would make it easier to change which programs were running on a desktop without switching away from it.