When running `wine explorer.exe /desktop=shell` as a full-screen app,
there is no obvious way to close it and return to the Linux desktop.
Remedy that problem by adding an "Exit desktop" button to the Start menu
in the same place as the "Shut Down" button on Windows.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4630
This fixes the layout of the tabcontrol when a font other than the
system font is used.
--
v9: comctl32/tests: Modify test_width to try different fonts
comctl32/tests: Check size initially and after changing padding only
comctl32/tests: Fix tabcontrol tests to work with different fonts
comctl32: Use selected font to determine default min tab width
https://gitlab.winehq.org/wine/wine/-/merge_requests/4484
--
v4: vkd3d: Co-locate all descriptor-related members.
vkd3d: Rename the device mutex to pipeline_cache_mutex.
vkd3d: Write Vulkan descriptors in a worker thread.
vkd3d: Update the descriptor `next` index before getting a reference for writing.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/292
This fixes various problems I've run into while trying to use Fusion 360 in wine.
- stacking issues in unmanaged mode
- I also attempted to apply the same fix for managed mode, but it looks difficult to do this in a way that plays well with window managers; I think it's best left up to them to keep override_redirect windows at the top of the stack)
- when the window manager sets our state to withdrawn, tell the window that it's been minimized, since the semantics are very similar
- the last one is a hack because I don't really know what to do about it, when clicking on the floating popups, they gain focus, which causes wine to incorrectly make them managed and that breaks everything
--
v3: winex11: don't let captionless popups be managed
winex11: pass ICCCM withdrawn state as minimized
winex11: restack a window's owned popups above it
https://gitlab.winehq.org/wine/wine/-/merge_requests/2343
On Thu Dec 7 18:47:06 2023 +0000, Rémi Bernon wrote:
> Well, code freeze is tomorrow so I don't intend to do anything soon.
> You can submit it in a separate MR if you think it's critical for the
> well behaving of the driver, and then @julliard will decide what to do
> with it, but I would personally wait until we try to fix these
> activation issues.
Thanks. As a possibly more freeze-safe alternative, I proposed a mitigation in the driver itself https://gitlab.winehq.org/wine/wine/-/merge_requests/4651 .
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4593#note_55533
These are all the patches in this area that I think make sense at this point in the release cycle (i.e. a couple of days before code freeze...)
I originally had many more. A few are not really suitable at this time; a couple turned out to not really make a difference or generally not feeling like it would be an improvement overall. Many ended up in the way (or not in the spirit) of what we probably want to do at some point, which is grouping the whole draw state setup data together with the draw itself. Not that I could find the time to explore that yet...
--
v2: wined3d: Add a bunch of d3d_perf traces.
wined3d: Add a frametime debug channel.
wined3d: Increase WINED3D_CS_QUERY_POLL_INTERVAL to 100.
wined3d: Sleep when waiting for the CS thread.
wined3d: Do a blocking wait for CS commands even when there are active queries.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4625