In the new version of Windows 11 (version 23H2, KB5034204), the change of desktops dosent work, and when changing between them the stack programs deorganize

[Kur0n3-112]

Describe the bug In the new version of Windows 11 (version 23H2, KB5034204), the change of desktops doesn't work, and when changing between them the stack programs de organize.

To Reproduce Steps to reproduce the behavior:

1. Windows Key + Shift
2. 1,.....,9 key number
3. See error

Expected behavior Change between desktops without, and that without de organize the programs.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. Windows 11]
• OS Build: 23H2, KB5034204
• FancyWM Version: v2.11.3-rc

Additional context Add any other context about the problem here.

[Minoo7]

Same

[mgazda]

I had the same issue. Out of curiosity, I downloaded source code and built it, to see if I can debug it and find anything useful. It turned out than when I run version built locally, the issue does not reproduce (neither in Debug nor Release) - both desktop switching and layouts work as intended. I use it as a temporary workaround, until someone more familiar with the project (or C#) finds the root cause :)

[Kur0n3-112]

@mgazda How did you do it? Cause i try to compile it in locale with the Debug version and it comes with the same problem when i change between workspaces it deorganize. Also thanks a lot for replying

[mgazda]

@Kur0n3-112 have you cloned the repo or downloaded the source code zip? I cloned repo (git clone --recursive https://github.com/FancyWM/fancywm.git), installed dependencies that Visual Studio asked me to (.NET SDK 8.0.101), built the solution and it works...

[Kur0n3-112]

@mgazda yes i do that but no lucky i guess there is something i dont do fine, but no clue

[mrcapivaro]

same

[Bureaucromancer]

The release preview is supposed to have fixed it, but the version uploaded appears to be the full release. #217

[emilio-toledo]

I have built the project locally and even with the whole source code the error is still reproducible.

[Kur0n3-112]

I have built the project locally and even with the whole source code the error is still reproducible.

Anyone knows how to fix it somehow, in the code or something?

[mgazda]

I think I've managed to fix this. There was a change in GUIDs of the interfaces used by underlying library (winman-windows). I've already submitted a pull request, but until then, feel free to use the branch with fix, which I have on my fork.

[Kur0n3-112]

@mgazda It works like a charm so much thanks you are a genius, i like to admit that i want to know how did you do it, cause i dont have so much idea about C#

[mgazda]

Well, I'm not a C# expert either, but when I was able to reproduce the issue, it was a little bit of debugging to figure out that there is and issue with getting IComVirtualDesktopManagerInternal interface with GUID.

Luckily, there was already mechanism that choose the right GUID based on Windows build number. It only needed the latest GUID added and chosen for the recent build numbers.

A little of googling, a bit of copy-pasting and it works :)

By the way, I created an Issue and a Pull Request in the WinMan-Windows repo. Hopefully @veselink1 will be able to merge it (or do a better job than I did) to fix it in the official version.

[Kur0n3-112]

That is really great, thanks everyone for replaying.

[innocenat]

I think this issue shouldn't be closed until the fix landed in the main repo.

[Kur0n3-112]

You are right @innocenat

[Minoo7]

Well, I'm not a C# expert either, but when I was able to reproduce the issue, it was a little bit of debugging to figure out that there is and issue with getting IComVirtualDesktopManagerInternal interface with GUID.

Luckily, there was already mechanism that choose the right GUID based on Windows build number. It only needed the latest GUID added and chosen for the recent build numbers.

A little of googling, a bit of copy-pasting and it works :)

By the way, I created an Issue and a Pull Request in the WinMan-Windows repo. Hopefully @veselink1 will be able to merge it (or do a better job than I did) to fix it in the official version.

How do I use this fork in FancyWm?

[mgazda]

How do I use this fork in FancyWm?

Well, until the pull request is merged, you'd need to clone this FancyWM repository (or download source code), and replace contents of winman-windows folder with contents of build23H2 branch of my fork. Then build and run.

If there is no update with the pull request soon, I'll try to fork the whole project and create a release that can be simply downloaded and run...

[Bureaucromancer]

I suspect thats the path this is going to have to go down… It’s a shame considering the original maintainer got this into the app store, but I rather suspect this was open sourced with the idea of getting away from maintaining it.

[whaaaley]

@Bureaucromancer I wouldn't be so quick to judge. It's frustrating as a user for sure, but it's a one man show. Also, afaik, the app as been free to compile on GitHub for years. It's not uncommon.

Also, I'm going to link #197 since this issue was fixed once before, but it seems to keep cropping up as Window's updates keep breaking stuff.

[veselink1]

@Bureaucromancer Your suspicions about why I open-sourced this are wrong. I'd say it was a mix of negative reviews on the MS Store regarding the closed-sourceness (which were entitled, but I caved in), and genuine hope that I will get some help for some of the features that I know I will never prioritise, as I won't benefit from them.

@mgazda Thank you for your PR 🥇! I really appreciate it, and it is the first PR to be merged to this project.

That being said, I am not on the version targeted by the PR, and have not tested. To clarify for everyone in the discussion, Microsoft provides no public virtual desktop API. There is an internal API which FancyWM tries to use, but it changes every few versions, and even more aggresively now with Windows 11. Any change will break FancyWM's ability to interact with virtual desktops.

I think the best way to address the problem, is to:

1. Ask Microsoft to implement a public Virtual Desktop API
2. Remove support from FancyWM until that is done, or at least, allow the warning to be disabled.

There's a new release with the PR on available on GitHub. My plan for the Microsoft Store is to pull the app down as it is a massive pain to maintain it there.

[Bureaucromancer]

For my part I'd wholly support allowing the warning to be disabled while marking Windows 11 support itself as highly experimental.

As far as #1, asking can't hurt, but honestly think any REAL effort would be better spent beggin for something more akin to rolling a tiling WM into powertoys than getting a true API.

On Sun, Mar 17, 2024 at 8:28 AM Vesko Karaganev @.***> wrote:

@Bureaucromancer https://github.com/Bureaucromancer Your suspicions about why I open-sourced this are wrong. I'd say it was a mix of negative reviews on the MS Store regarding the closed-sourceness (which were entitled, but I caved in), and genuine hope that I will get some help for some of the features that I know I will never prioritise, as I won't benefit from them.

@mgazda https://github.com/mgazda Thank you for your PR 🥇! I really appreciate it, and it is the first PR to be merged to this project.

That being said, I am not on the version targeted by the PR, and have not tested. To clarify for everyone in the discussion, Microsoft provides no public virtual desktop API. There is an internal API which FancyWM tries to use, but it changes every few versions, and even more aggresively now with Windows 11. Any change will break FancyWM's ability to interact with virtual desktops.

I think the best way to address the problem, is to:

1. Ask Microsoft to implement a public Virtual Desktop API
2. Remove support from FancyWM until that is done, or at least, allow the warning to be disabled.

There's a new release with the PR on available on GitHub. My plan for the Microsoft Store is to pull the app down as it is a massive pain to maintain it there.

— Reply to this email directly, view it on GitHub https://github.com/FancyWM/fancywm/issues/213#issuecomment-2002441172, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJOMKLHETNIIWZG3UNN2ZTYYWEATAVCNFSM6AAAAABCLDQJUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGQ2DCMJXGI . You are receiving this because you were mentioned.Message ID: @.***>

[riotrah]

I really hate this internal vDesktop API stuff, I know there's no real financial incentive for MS to stabilize and make it public, but I've seen it prevent other Windows WM projects from even touching VDs.

I was initially doubtful that a TWM in PT would get the UX "right" in the way that I like FWM's or Amethyst's, but the upside of a TWM plugin running into limitations of the VD API would be community noise about it might surface the issue to MS, which might improve the situation for everyone, including this project.

In any case, would 2 new settings be good for this project?

• Opt into "experimental native multiple desktop support"
• Ignore the supported version warning (or "only show me once per buggy version" or something)

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.