Skip to content
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

Tiling Layouts are Sometimes Lost (After user switching) #948

Open
LearnLinuxTV opened this issue Apr 20, 2021 · 12 comments · Fixed by #975
Open

Tiling Layouts are Sometimes Lost (After user switching) #948

LearnLinuxTV opened this issue Apr 20, 2021 · 12 comments · Fixed by #975

Comments

@LearnLinuxTV
Copy link

(1) Issue/Bug Description:
Every now and then, I lose my tiling layout, and I need to recreate it. For example, I may have a window tiled to the left, and I like it there. Perhaps I'll also have a tab stack with related windows together. After a while, I'll lose this entire layout and I'll have to redo it.

(2) Steps to reproduce (if you know):
Although this isn't the only time I experience this, one method that often reproduces this is as follows:

  1. Set up your windows in tiling mode the way you like them. I always use tab stacks so maybe create one of those too.
  2. Switch user using the system controls on the upper-right. Don't log out, just switch to another user while leaving your current user logged in.
  3. Log out of that user, then resume your original user session.
  4. You should notice that your tiling layout is completely reset, and you'll have to organize it all over again.

I've also had success reproducing this sometimes while just restarting GNOME after setting up my windows.

If it makes a difference, I always use workspaces fairly heavily. I usually have 7+ workspaces in GNOME at any one time.

(3) Expected behavior:
Having to re-organize your windows is a pain, and having to recreate tab stacks is even worse. Tiling layouts and tab stacks should be remembered. I think it's reasonable to lose your layout if you log out, but you should never lose your layout while the session is active.

(4) Distribution (run cat /etc/os-release):

VERSION="20.10"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 20.10"
VERSION_ID="20.10"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=groovy
UBUNTU_CODENAME=groovy
LOGO=distributor-logo-pop-os```


**(5) Gnome Shell version:**
3.38


**(6) Pop Shell version (run `apt policy pop-shell` or provide the latest commit if building locally):**
```pop-shell:
  Installed: 1.1.0~1617950178~20.10~163d207
  Candidate: 1.1.0~1617950178~20.10~163d207
  Version table:
 *** 1.1.0~1617950178~20.10~163d207 1001
       1001 http://ppa.launchpad.net/system76/pop/ubuntu groovy/main amd64 Packages
       1001 http://ppa.launchpad.net/system76/pop/ubuntu groovy/main i386 Packages
        100 /var/lib/dpkg/status```


**(7) Where was Pop Shell installed from:**
ISO, downloaded from official site


**(8) Monitor Setup (2 x 1080p, 4K, Primary(Horizontal), Secondary(Vertical), etc):**
Resolution: 5120x1440
119.97hz refresh


**(9) Other Installed/Enabled Extensions:**
Other than the default, I installed "NoAnnoyance", but this issue started happening before I installed any plugins.


**(10) Other Notes:**



@bflanagin bflanagin changed the title Tiling Layouts are Sometimes Lost Tiling Layouts are Sometimes Lost (After user switching) Apr 21, 2021
@LearnLinuxTV
Copy link
Author

In regards to changing the title to mention user switching, I am not sure if I agree with that. It happens even without switching users, the user-switching thing was just one way of reproducing it. It's not the only way.

@mmstick
Copy link
Member

mmstick commented Apr 29, 2021

Yeah this is a general issue we've had from the getgo with workspaces in GNOME Shell. As much as I've tried to work around it, I think my best option moving forward is to look into injecting an override for redoing workspace handling entirely to make it work the Pop Shell way. GNOME just shuffles workspaces every time there is any sort of display update, and it throws windows around in the process which confuses the tiling system.

@BobbyByrne
Copy link
Contributor

I can replicate this just by using the Lock feature.

NAME="Pop!_OS"
VERSION="20.10"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 20.10"
VERSION_ID="20.10"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=groovy
UBUNTU_CODENAME=groovy
LOGO=distributor-logo-pop-os

@BobbyByrne
Copy link
Contributor

GNOME just shuffles workspaces every time there is any sort of display update, and it throws windows around in the process which confuses the tiling system.

Makes sense given toggling from Dynamic to static workspaces messes around with the tiles as well.

@LearnLinuxTV
Copy link
Author

LearnLinuxTV commented May 13, 2021

Makes sense given toggling from Dynamic to static workspaces messes around with the tiles as well.

That situation CAN make sense, but the issue happens even if there's no actual reason for a display update. For example, I use tiling mostly on my desktop. The monitor and resolution never changes. Yet, I'm constantly losing my layout many times per day. It's to the point where I may disable tiling since it doesn't really do me any good, I never know where anything is going to be at this point. If I were using a laptop and I was docking and undocking my laptop to a docking station with another monitor, then I would probably forgive this bug in that case (maybe). But a desktop, as you know, is much more static.

@BobbyByrne
Copy link
Contributor

BobbyByrne commented May 21, 2021

But a desktop, as you know, is much more static.

I meant toggling the gsettings option of dynamic workspaces (can be found in gnome tweaks), also causes the issue. I completely agree with expected behavior you outline.

@mmstick mmstick mentioned this issue May 21, 2021
mmstick added a commit that referenced this issue Jun 7, 2021
@Pathos14489
Copy link

I'd like to say that this hasn't been fixed even in 22.04, and it's honestly the worst thing I've ever had to deal with on a computer aside from how nice it is when it actually works. But reorganizing it like 3-4 times a day 'cause I locked my screen or my cable got unplugged for some reason is a fucking drag man.

@LearnLinuxTV
Copy link
Author

I agree, this should be reopened.

I’m also surprised by the closed status, I must not have seen an alert on this - this issue was never resolved.

@BobbyByrne
Copy link
Contributor

Agreed. Issue still occurs after locking the screen, when enabling or disabling certain Gnome extensions, and when plugging and unplugging monitors. I don't see why windows should switch workspaces when a new monitor is plugged in. I've seen some threads that suggest the issue is with Gnome and how it doesn't keep track of workspace positions.

@leviport leviport reopened this Jun 21, 2022
@tartley
Copy link

tartley commented Apr 26, 2023

This is one of a bunch of issues that sound like dupes to me. I think perhaps this issue should be closed as a dupe of the best populated one, #917.

If you care about this issue, please go and upvote (thumbs up) that one too, so we can at consolidate our votes to show that a whole bunch of people care about this family of issues.

@LearnLinuxTV
Copy link
Author

LearnLinuxTV commented Apr 26, 2023

The problem with consolidating this into bug 917 is that it assumes that this only happens with external displays. I've experienced this on a Desktop with a display that's never unplugged for any reason (or even changed, for that matter).

@tartley
Copy link

tartley commented Apr 26, 2023

@LearnLinuxTV Ah, ok, fair. Thanks for the clarity. Perhaps I spoke too quickly. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants