Implements navigation bar featuring:
- back/forward buttons
- go up button
- address crumbs
- hides crumbs when there's not enough space to display all of them
- always shows at least 2 crumbs
- truncating them if needed
- first crumb is at least 56px
- aligns label to the left if truncated
- right clicking on the crumb, or free space, opens a menu with `Copy address as text` and `Edit address` options
- reuses existing crumbs to avoid some flickering
- overflow menu
- ~~first crumb is always moved here~~
- removes the split, if there are no items in the menu
- hidden crumbs are moved here
- left ~~or right~~ click on the button starts address editing
- address edit
- accepts an existing path
- expands environment variables, e.g. `%APPDATA%\Microsoft` -> `C:\users\%USERNAME%\AppData\Roaming\Microsoft`
- errors with a `MessageBox` on nonexistent paths
- refresh button
- changes into go to button when editing address
- DPI scaling
Screenshots:






Remaining issues:
- crumbs not lighting up when hovered sometimes
- can be observed in current file dialog, hovering over dropdown arrow of a file type fixes it for a moment
- crumbs flickering on address change sometimes
- mostly when there's not enough space to display all of them
- `DeferWindowPos` doesn't seem to be atomic in Wine, presumably is in native Windows?
- unexpected address conversion for some PIDLs
- e.g. `Desktop` -> `C:\users\%USERNAME%\Desktop`, which is an entirely different location
- or `My Computer` into an empty string
- known folders are not handled by address edit, e.g. `Desktop`, `My Computer`
- icons are not DPI scaled
- while writing this:
```
0024:fixme:bitmap:NtGdiCreateBitmap planes = 0
0024:err:system:user_check_not_lock BUG: holding USER lock
wine/dlls/win32u/sysparams.c:396: user_check_not_lock: Assertion `0' failed.
wine: Assertion failed at address F7FF8549 (thread 0024), starting debugger...
```
- can't reproduce, happened when clicking on an item in overflow menu
- race condition? cosmic ray?
Addresses following bugs:
- https://bugs.winehq.org/show_bug.cgi?id=29912
- https://bugs.winehq.org/show_bug.cgi?id=50338
- https://bugs.winehq.org/show_bug.cgi?id=51855 (partially? no search box)
--
v12: fixup: comdlg32: Add address edit to IFileDialog navigation bar.
comdlg32: Add refresh/go to button to IFileDialog navigation bar.
comdlg32: Add address edit to IFileDialog navigation bar.
comdlg32: Add breadcrumb overflow menu to IFileDialog navigation bar.
comdlg32: Add address breadcrumbs to IFileDialog navigation bar.
comdlg32: Add go up button to IFileDialog navigation bar.
comdlg32: Add IFileDialog navigation bar.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1857
Some window managers have trouble moving fullscreen windows to another monitor. For example, KWin
doesn't allow moving windows with _NET_WM_STATE_FULLSCREEN set. FVWM used by TestBots keeps
the size for fullscreen windows after they are moved to another monitor and when the window is also
fullscreen on the new monitor, which could be a bug in FVWM. But let's work around this in the tests
as well. The changed tests don't need created windows being fullscreen at the start.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54172
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1932
copy_propagation_transform_object_load() currently retrieves true, which
indicates that there was progress, even if the input dereference remains
the same.
This can happen repeatedly if an uninitialized object is copied onto
itself, as in the tests added in this patch. This results on the
compilation getting stuck on an endless loop.
This patch checks if the deref didn't change, to retrieve false in that
case.
--
v5: vkd3d-shader/hlsl: Validate that referenced objects are uniform.
tests: Test uninitialized object references.
vkd3d-shader/hlsl: Avoid infinite loop in copy propagation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/59
LOCALE_SGROUPING's string and the `Grouping` field in NUMBERFMTW are confusingly different. The former, which is what is fixed here, treats a '0' as a repeat of the previous grouping. But a 0 at the end of the `Grouping` field prevents it from repeating (it repeats by default otherwise) so it's the opposite. Note that without a '0' in the LOCALE_SGROUPING string, it shouldn't even repeat in the first place.
This fixes the typical "3;0" default grouping, for example.
See: https://learn.microsoft.com/en-us/windows/win32/intl/locale-sgrouping
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1937
copy_propagation_transform_object_load() currently retrieves true, which
indicates that there was progress, even if the input dereference remains
the same.
This can happen repeatedly if an uninitialized object is copied onto
itself, as in the tests added in this patch. This results on the
compilation getting stuck on an endless loop.
This patch checks if the deref didn't change, to retrieve false in that
case.
--
v4: vkd3d-shader/hlsl: Validate that referenced objects are uniform.
tests: Test uninitialized object references.
vkd3d-shader/hlsl: Avoid infinite loop in copy propagation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/59
We are currently not initializing static values to zero by default.
Consider the following shader:
```hlsl
static float4 va;
float4 main() : sv_target
{
return va;
}
```
we get the following output:
```
ps_5_0
dcl_output o0.xyzw
dcl_temps 2
mov r0.xyzw, r1.xyzw
mov o0.xyzw, r0.xyzw
ret
```
where r1.xyzw is not initialized.
This patch solves this by assigning the static variable the value of an
uint 0, and thus, relying on complex broadcasts.
This seems to be the behaviour of the the native compiler, since it retrieves
the following error on a shader that lacks an initializer on a data type with
object components:
```
error X3017: cannot convert from 'uint' to 'struct <unnamed>'
```
--
v6: vkd3d-shader/hlsl: Allow uninitialized static objects.
vkd3d-shader/hlsl: Validate that non-uniform objects are not referenced.
tests: Add additional object references tests.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/54
--
v3: vkd3d-shader/hlsl: Get rid of the "intrinsic" field of struct hlsl_ir_function.
vkd3d-shader/hlsl: Forbid returning void expressions from void functions.
vkd3d-shader/hlsl: Generate IR for user-defined function calls.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/47
For the console tests, I prefer to run new/modified tests on all VM configurations so I can quickly see which behaviour or return codes are commonly correct. In some cases, this lets me determine in which version some expected behaviour changed.
This all started with the font family registry value MR. I wanted to check the value name on XP, since I thought it was correct but couldn’t be certain. That’s when I discovered the tests weren’t running and decided to see how much effort it would take to fix them.
I know the value of these patches isn’t worth much, but I still find them useful.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1899#note_20678
> I don't see the maintenance cost or burden as high, nor do I mind monitoring this, if that's a concern.
Seeing the number of patches you had to write (and will have to continue to write on an ongoing basis), I'd say the cost is significant.
What's the upside? What behavior do you need to test on XP, and why?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1899#note_20671
I don't see the maintenance cost or burden as high, nor do I mind monitoring this, if that's a concern.
Looking at recent test patches, I can see function addresses used. It's really only adding the macro part, then calling the pointer. Everything else is the same as normal.
I think I'm actually to blame for the issues in the console tests...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1899#note_20669
> There are times when it is useful to test changes on the Windows XP and 2003 VMs, but the direct use of functions not on those platforms makes this impossible.
>
> Once applied, the kernel32 tests will run on the Windows XP and 2003 testbot VMs.
We have decided to no longer care about XP/2003 results, precisely because the maintenance cost of keeping the tests running is bigger than the benefits of supporting obsolete platforms.
If there's a case where you need to investigate the XP/2003 behavior, I'd suggest extracting just that test to a separate exe.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1899#note_20668