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

Switching Windows virtual desktops breaks layout #15

Closed
naoey opened this issue Aug 19, 2021 · 4 comments
Closed

Switching Windows virtual desktops breaks layout #15

naoey opened this issue Aug 19, 2021 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@naoey
Copy link

naoey commented Aug 19, 2021

Tiling works perfectly on starting komorebi up but windows get smaller and smaller each time I switch to and from other virtual desktops. In some cases its just one window that's affected in some cases its all the windows on that virtual desktop. I haven't been able to identify a pattern to it so far.

Unsure if its once again related to me having a multi-monitor configuration. I use:

  • 2560x1440 primary
  • 3840x2160 (scaled to 2560x1440) secondary

This is occurring both when using the pre-built release as well as when building it myself on 98f731b.

image

@LGUG2Z
Copy link
Owner

LGUG2Z commented Aug 19, 2021

@naoey Can you confirm that this is happening when switching between the native Windows Virtual Desktops and not komorebi's implementation of workspaces?

If this is happening with komorebi's implementation of workspaces it is definitely a bug and it would help if you could record a video of this happening so that I can try to accurately reproduce it.

komorebi generally doesn't aim for compatibility with Windows Virtual Desktops, because the public API is extremely lacking. In fact, it is the lack of stability around advanced programmatic access to Windows Virtual Desktops that led me to create a completely independent workspaces implementation for komorebi.

Nevertheless, I would be tempted to at least try to fix this specific bug, because the fix would help to ensure that while komorebi doesn't provide compatibility and interoperability with Windows Virtual Desktops, it also does not permit Windows Virtual Desktops to introduce weird/undefined/breaking behaviour into the komorebi process.

@naoey
Copy link
Author

naoey commented Aug 19, 2021

Yes, sorry if that wasn't clear. I did mean this is occurring with Windows Virtual Desktops.

komorebi generally doesn't aim for compatibility with Windows Virtual Desktops, because the public API is extremely lacking

That's completely understandable. I'm somewhat accustomed to using them as the Windows equivalent of Spaces on macOS so even if not feasible to get the same level of compatibility as yabai provides, just having it not disrupt the layout would be great!

@LGUG2Z LGUG2Z closed this as completed in 74811fb Aug 19, 2021
@LGUG2Z LGUG2Z self-assigned this Aug 19, 2021
@LGUG2Z LGUG2Z added the bug Something isn't working label Aug 19, 2021
@LGUG2Z
Copy link
Owner

LGUG2Z commented Aug 19, 2021

@naoey I have made some changes that limit the komorebi listeners to the Windows Virtual Desktop that the process was started from. In practice, this means that you can have a single Virtual Desktop which runs komorebi with komorebi's implementation of workspaces, and other Virtual Desktops that know nothing about komorebi and which komorebi knows nothing about. 👌

LGUG2Z added a commit that referenced this issue Aug 19, 2021
Of course, the crate built to interact with an undocumented COM API is
not the best candidate for unwrap and expect calls...

fix #15
@es183923
Copy link

es183923 commented Aug 1, 2022

Looks like this still is happening when switching between windows' virtual desktops when building from master a6d46db.

Komorebi seems to forget that windows were minimized, and results in it allocating space for minimized windows, which it shouldn't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants