All windows share one WM_CLASS

[awsms]

• All the windows created by FreeRDP have the same WM_CLASS property. If I open Visual Studio, MSPaint, then PowerShell, all the windows will have the WM_CLASS(STRING) = "RAIL", "Microsoft Powershell" properties (very likely a FeeRDP limitation). edit: https://github.com/FreeRDP/FreeRDP/issues/6570#issuecomment-725878476

• I have graphical glitches when opening winapps programs / rearranging the screen layout

Then I can see the windows decorations in other workspaces:

• Context menus (right-click) are often a black rectangle in various programs (like the Windows Explorer)

[AkechiShiro]

Can you try on SwayVM and report if you have the same issue as on i3WM ?

[fitzmorrispr]

RE WM_CLASS: It's not necessarily a FreeRDP issue. It is probably technically possible for FreeRDP to use WinAPI calls (Such as GetClassName (!)) to query every window's strings, and use those with a lookup table to assign appropriate window classes, but such a table would either have very poor coverage, or would be enormous, and even then it would have edge cases for days, as this is really not the purpose of those strings.

The aforementioned ClassName identifies groups of windows, but not per-application, and the names are only really meaningful to the programmer of the specific app. So, Excel Userforms (made in the VBE) are either "ThunderDFrame" or "ThunderXFrame" depending on excel version, but the main window is something else, the VBE window is a third thing, etc.

The problem could be worked around by using a Windows Server install with Terminal Services, which then allows multiple RDP sessions per user, and therefore multiple FreeRDP processes each with different WM_CLASS ,but that costs money.

Probably regular windows is capable of doing this too, but the functionality is certainly not made available

RE: the visual glitch issue: I don't use Visual Studio, so I can't tell you for sure what's going on here, but:

Windows apps can have multiple windows per visible window. The windows API allows for the creation of single buttons in a dialog box, but crucially, when made this way, each button is actually a full fledged window, with its own window handle. the thing that makes them behave as though they are part of the window they appear with is all API glue, WM_PAINT events and such.

there's also GDI calls for painting outside the normal boundaries (without them, the process is limited to painting inside its window frame)

This all works fine in the windows environment, obviously a desktopless (the windows Desktop is a Window! it has an hWnd and properties!) RDP session in a non-windows environment might not implement every winAPI event, property, and method necessary to avoid glitches like you describe

I'm using XFCE, and my windows explorer context menus work, so there may be wm related issues in play as well, but:

it MIGHT be that those decorations are actually [a] window[s] with their hWndInsertAfter set to HWND_TOPMOST ( = -1) when the vscode window is Active (vscode.hWnd == GetForegroundWindow()), and set to HWND_NOTOPMOST ( = -2 ) or HWND_BOTTOM ( = 1) when the vscode window is made inactive ('vscode.hWnd != GetForegroundWindow()`)

Thing is, switching to a non-windows window cannot trigger the code that triggers on making another window active, because you have to have the handle of a Windows window to call SetForegroundWindow(hWnd)

If this is what's going on, usage of Spy++ inside of a full RDP session would likely reveal it.