[win32][arm64] Support Dark Theme on newer Windows builds #1172

hmartinez82 · 2024-04-13T20:50:28Z

Here's the disassembly:

00007FFA2A1D3E10 D503237F             pacibsp  
00007FFA2A1D3E14 F81F0FF3             str         x19,[sp,#-0x10]!  
00007FFA2A1D3E18 A9BF7BFD             stp         fp,lr,[sp,#-0x10]!  
00007FFA2A1D3E1C 910003FD             mov         fp,sp  
00007FFA2A1D3E20 B00007E8             adrp        x8,wil::details::g_enabledStateManager+40h (07FFA2A2D0000h)  
00007FFA2A1D3E24 B94BB913             ldr         w19,[x8,#0xBB8]  
00007FFA2A1D3E28 2A0003E1             mov         w1,w0  
00007FFA2A1D3E2C 912EE100             add         x0,x8,#0xBB8  
00007FFA2A1D3E30 97FF7910             bl          _InterlockedExchange (07FFA2A1B2270h)  
00007FFA2A1D3E34 2A1303E0             mov         w0,w19  
00007FFA2A1D3E38 A8C17BFD             ldp         fp,lr,[sp],#0x10  
00007FFA2A1D3E3C F84107F3             ldr         x19,[sp],#0x10  
00007FFA2A1D3E40 D50323FF             autibsp  
00007FFA2A1D3E44 D65F03C0             ret

The add x0,x8, instruction changed its parameter. So now the adrp x8,... instruction looks more stable because it uses a global variable (Using a global variable is also what is done when validating for the Intel x64 uxtheme.dll)

See https://developer.arm.com/documentation/ddi0602/2024-03/Base-Instructions/ADRP--Form-PC-relative-address-to-4KB-page-

functionPtr[0x10] & 0x1F) == 0x08 checks that the destination register is x8
(functionPtr[0x13] & 0x90) == 0x90 checks that the opcode is ADRP

github-actions · 2024-04-13T20:58:40Z

Test Results

418 files ±0 418 suites ±0 7m 19s ⏱️ -50s
4 121 tests ±0 4 113 ✅ ±0 8 💤 ±0 0 ❌ ±0
16 313 runs ±0 16 221 ✅ ±0 92 💤 ±0 0 ❌ ±0

Results for commit a0c4d79. ± Comparison against base commit b435cb8.

♻️ This comment has been updated with latest results.

chirontt · 2024-04-14T02:49:33Z

Thanks for your quick work! I now have the dark scrollbars again in my Arm64 box. Here are how I test it:

merge this PR to my fork, and then locally rebuild the SWT native binaries by:

cd binaries\org.eclipse.swt.win32.win32.aarch64
del swt*.dll
mvn clean process-resources -Dnative=win32.win32.aarch64

The above mvn command would produce the updated SWT native (swt*.dll) files in the current directory.

create the module jar file which would embed the above SWT natives:

mvn clean verify

and the org.eclipse.swt.win32.win32.aarch64-3.126.0-SNAPSHOT.jar file is generated in the target directory.

manually run the Java test file Bug562043_DarkTableNoHover.java, using the above jar file in the classpath:

java -cp target\org.eclipse.swt.win32.win32.aarch64-3.126.0-SNAPSHOT.jar ^
..\..\tests\org.eclipse.swt.tests.win32\ManualTests\org\eclipse\swt\tests\win32\snippets\Bug562043_DarkTableNoHover.java

and the test program shows correct dark scrollbars in its window:

For comparison, here's the same window (with lighted scrollbars) before this fix:

chirontt · 2024-04-14T03:02:12Z

Further more, I've built the complete Eclipse SDK with this fix, from my aggregator fork, and here's its main window showing nicely dark scrollbars on my Arm64 box:

In previous builds before this fix, it was showing lighted scrollbars, which alerted me to the changed uxtheme.dll file due to recent Windows Arm64 update.

HannesWell · 2024-05-08T18:54:34Z

@niraj-modi or @SyntevoAlex could you please review this? I have no clue about the native code and no way to test it.

SyntevoAlex · 2024-05-09T00:46:16Z

The new test looks quite weak to me, because adrp x8, ??? is a rather common instruction which doesn't really identify the function we need for the dark theme.

I suggest that instead both offsets 0xBB8 and 0xBD8 are recognized (to recognize both windows versions)

hmartinez82 · 2024-05-09T00:53:42Z

@SyntevoAlex ah good idea. I'll work on that tomorrow :)

hmartinez82 · 2024-05-10T07:59:05Z

@chirontt can you try with the latest changes? I changed the title of the PR too

SyntevoAlex · 2024-05-10T13:38:25Z

It would be nice to also have code comments with Windows versions, like here:

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/library/os_custom.c

Lines 124 to 138 in 1a35d6e

    
           /* Win10 builds from 21301 */ 
        
           if ((functionPtr[0x31] == 0xBA) &&                      // mov      edx, 
        
           	(*(const DWORD*)(functionPtr + 0x32) == 0xA91E))    //              0A91Eh 
        
           { 
        
           	return TRUE; 
        
           } 
        
           /* Win11 builds from 22621 */ 
        
           if ((functionPtr[0x15] == 0xBA) &&                      // mov      edx, 
        
           	(*(const DWORD*)(functionPtr + 0x16) == 0xA91E))    //              0A91Eh 
        
           { 
        
           	return TRUE; 
        
           } 
        
           return FALSE;

SyntevoAlex · 2024-05-10T13:39:16Z

^ this is just a suggestion, I will still approve without it.

hmartinez82 · 2024-05-10T13:39:41Z

I don't have the old versions. @chirontt Can you find me the Windows builds before and after the original PR stopped working?

chirontt · 2024-05-10T21:18:51Z

Can you find me the Windows builds before and after the original PR stopped working?

I'm not quite sure I follow you here. It's not the Eclipse build that stops working; it's the recent (last month's) Windows Arm64 update that causes the problem due to changes in the uxtheme.dll in the Windows update. With your latest Windows version running in your Arm64 box, the lighted scrollbar problem appears, for any Eclipse WoA versions.

You can grab the latest build of the Eclipse SDK here especially the WoA zip package. Just unzip it and run the Eclipse IDE, put it in dark mode and you'll see the lighted scrollbars in the IDE. This latest build contains your original commit for the os_custom.c file.

To see if/how it works before, you need to restore your WoA box to before the current (last month's) Windows update, and test it with the same Eclipse SDK mentioned above. You'd see the dark scrollbars as intended.

chirontt · 2024-05-10T21:33:01Z

can you try with the latest changes? I changed the title of the PR too

I've tried the same steps as in my previous comment, and the scrollbars are still properly in dark mode, with your latest fix. Here's the screenshot of the Bug562043_DarkTableNoHover.java test:

SyntevoAlex · 2024-05-10T22:19:19Z

@chirontt Just to clarify:

Before this PR, on your newest Windows, scrollbars are light
With this PR, on your newest Windows, scrollbars are dark once again
is that correct?

If yes, please run ver in your commandline and give us Windows version number (where it was broken and now once again fixed).

chirontt · 2024-05-10T22:56:40Z

* Before this PR, on your newest Windows, scrollbars are light

Yes.

* With this PR, on your newest Windows, scrollbars are dark once again
  is that correct?

Yes.

If yes, please run ver in your commandline and give us Windows version number (where it was broken and now once again fixed).

>ver

Microsoft Windows [Version 10.0.22631.3447]

SyntevoAlex · 2024-05-16T18:23:10Z

@hmartinez82 to clarify, I'm waiting for you. @chirontt already got the version numbers, see above.

SyntevoAlex · 2024-05-16T19:01:01Z

Please squash commits (because separating them does not convey any additional value here), you can use PR title as commit message. Then it can be merged.

chirontt · 2024-05-17T02:49:55Z

@SyntevoAlex , @hmartinez82 Sorry to sound like a broken record again, but the new Windows update this week (last Tuesday, to be precise) breaks this os_custom.c file again for WoA. The current WoA version on my box is now:

>ver

Microsoft Windows [Version 10.0.22631.3593]

and running the Bug562043_DarkTableNoHover.java test on it now shows the light scrollbars in dark mode:

I've checked the file date of uxtheme.dll and surely enough, it was updated last Tuesday:

>dir \Windows\System32\uxtheme.dll
 Volume in drive C has no label.
 Volume Serial Number is 7EBE-F3EB

 Directory of C:\Windows\System32

05/14/2024  08:01 PM         1,223,680 uxtheme.dll
               1 File(s)      1,223,680 bytes
               0 Dir(s)  96,054,374,400 bytes free

hmartinez82 · 2024-05-17T03:02:24Z

The argument changed again, it's 0xBF8 now in SetPreferredAppMode()

00007FFD7EE92890 D503237F             pacibsp  
00007FFD7EE92894 F81F0FF3             str         x19,[sp,#-0x10]!  
00007FFD7EE92898 A9BF7BFD             stp         fp,lr,[sp,#-0x10]!  
00007FFD7EE9289C 910003FD             mov         fp,sp  
00007FFD7EE928A0 F00007E8             adrp        x8,wil::details::g_enabledStateManager+40h (07FFD7EF91000h)  
00007FFD7EE928A4 B94BF913             ldr         w19,[x8,#0xBF8]  
00007FFD7EE928A8 2A0003E1             mov         w1,w0  
00007FFD7EE928AC 912FE100             add         x0,x8,#0xBF8  
00007FFD7EE928B0 97FF7E70             bl          _InterlockedExchange (07FFD7EE72270h)  
00007FFD7EE928B4 2A1303E0             mov         w0,w19  
00007FFD7EE928B8 A8C17BFD             ldp         fp,lr,[sp],#0x10  
00007FFD7EE928BC F84107F3             ldr         x19,[sp],#0x10  
00007FFD7EE928C0 D50323FF             autibsp  
00007FFD7EE928C4 D65F03C0             ret

I think that chasing this value is not a good idea. It keeps changing, it seems very unstable across builds of uxtheme.dll. The line above, which deals with the global value has been stable across all the changes we've seen so far. The code detection for Intel is doing exactly that. See

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/library/os_custom.c

Line 233 in a39c321

    
           (functionPtr[0x00] == 0x8B) && (functionPtr[0x01] == 0x05) &&   // mov     eax,dword ptr [uxtheme!g_preferredAppMode]

What if I do what I did originally ? And also add a test for the location of the ret instruction? That's what's being done for Intel x64 too.

hmartinez82 · 2024-05-17T03:22:48Z

@chirontt Try with the change from 1 min ago.

chirontt · 2024-05-17T03:57:14Z

@chirontt Try with the change from 1 min ago.

Yes, it works now, i.e. the scrollbars are now dark:

SyntevoAlex · 2024-05-17T19:15:44Z

The code detection for Intel is doing exactly that

This is not right, it checks a lot more: it checks that two instructions mention the SAME global variable.

eclipse.platform.swt/bundles/org.eclipse.swt/Eclipse SWT PI/win32/library/os_custom.c

Lines 227 to 230 in a39c321

    
           const DWORD varOffset1 = *(const DWORD*)(functionPtr + 0x02); 
        
           const DWORD varOffset2 = *(const DWORD*)(functionPtr + 0x08); 
        
           if (varOffset1 != (varOffset2 + 6)) 
        
           	return FALSE;

hmartinez82 · 2024-05-17T19:38:51Z

Given the three disassembles we've seen so far, what do you recommend?

00007FFB16C33E10 D503237F             pacibsp  
00007FFB16C33E14 F81F0FF3             str         x19,[sp,#-0x10]!  
00007FFB16C33E18 A9BF7BFD             stp         fp,lr,[sp,#-0x10]!  
00007FFB16C33E1C 910003FD             mov         fp,sp  
00007FFB16C33E20 D00007E8             adrp        x8,wil::details::g_enabledStateManager+40h (07FFB16D31000h)  
00007FFB16C33E24 B94BD913             ldr         w19,[x8,#0xBD8]  
00007FFB16C33E28 2A0003E1             mov         w1,w0  
00007FFB16C33E2C 912F6100             add         x0,x8,#0xBD8  
00007FFB16C33E30 97FF7910             bl          _InterlockedExchange (07FFB16C12270h)  
00007FFB16C33E34 2A1303E0             mov         w0,w19  
00007FFB16C33E38 A8C17BFD             ldp         fp,lr,[sp],#0x10  
00007FFB16C33E3C F84107F3             ldr         x19,[sp],#0x10  
00007FFB16C33E40 D50323FF             autibsp  
00007FFB16C33E44 D65F03C0             ret

00007FFA2A1D3E10 D503237F             pacibsp  
00007FFA2A1D3E14 F81F0FF3             str         x19,[sp,#-0x10]!  
00007FFA2A1D3E18 A9BF7BFD             stp         fp,lr,[sp,#-0x10]!  
00007FFA2A1D3E1C 910003FD             mov         fp,sp  
00007FFA2A1D3E20 B00007E8             adrp        x8,wil::details::g_enabledStateManager+40h (07FFA2A2D0000h)  
00007FFA2A1D3E24 B94BB913             ldr         w19,[x8,#0xBB8]  
00007FFA2A1D3E28 2A0003E1             mov         w1,w0  
00007FFA2A1D3E2C 912EE100             add         x0,x8,#0xBB8  
00007FFA2A1D3E30 97FF7910             bl          _InterlockedExchange (07FFA2A1B2270h)  
00007FFA2A1D3E34 2A1303E0             mov         w0,w19  
00007FFA2A1D3E38 A8C17BFD             ldp         fp,lr,[sp],#0x10  
00007FFA2A1D3E3C F84107F3             ldr         x19,[sp],#0x10  
00007FFA2A1D3E40 D50323FF             autibsp  
00007FFA2A1D3E44 D65F03C0             ret

00007FFD7EE92890 D503237F             pacibsp  
00007FFD7EE92894 F81F0FF3             str         x19,[sp,#-0x10]!  
00007FFD7EE92898 A9BF7BFD             stp         fp,lr,[sp,#-0x10]!  
00007FFD7EE9289C 910003FD             mov         fp,sp  
00007FFD7EE928A0 F00007E8             adrp        x8,wil::details::g_enabledStateManager+40h (07FFD7EF91000h)  
00007FFD7EE928A4 B94BF913             ldr         w19,[x8,#0xBF8]  
00007FFD7EE928A8 2A0003E1             mov         w1,w0  
00007FFD7EE928AC 912FE100             add         x0,x8,#0xBF8  
00007FFD7EE928B0 97FF7E70             bl          _InterlockedExchange (07FFD7EE72270h)  
00007FFD7EE928B4 2A1303E0             mov         w0,w19  
00007FFD7EE928B8 A8C17BFD             ldp         fp,lr,[sp],#0x10  
00007FFD7EE928BC F84107F3             ldr         x19,[sp],#0x10  
00007FFD7EE928C0 D50323FF             autibsp  
00007FFD7EE928C4 D65F03C0             ret

SyntevoAlex · 2024-05-17T19:52:54Z

Here's the diff

D503237F pacibsp
F81F0FF3 str  x19,[sp,#-0x10]!  
A9BF7BFD stp  fp,lr,[sp,#-0x10]!  
910003FD mov  fp,sp  
D00007E8 adrp x8,wil::details::g_enabledStateManager+40h (07FFB16D31000h)  
B94BD913 ldr  w19,[x8,#0xBD8]  
2A0003E1 mov  w1,w0  
912F6100 add  x0,x8,#0xBD8  
97FF7910 bl   _InterlockedExchange (07FFB16C12270h)  
2A1303E0 mov  w0,w19  
A8C17BFD ldp  fp,lr,[sp],#0x10  
F84107F3 ldr  x19,[sp],#0x10  
D50323FF autibsp  
D65F03C0 ret  

........ .......
........ ...  ................
........ ...  ..................
........ ...  .....
........ .... .......................................... (07FFA2A2D0000h)
........ ...  ........#0xBB8.
........ ...  .....  
........ ...  ......#0xBB8  
........ ..   .................... (07FFA2A1B2270h)  
........ ...  ......  
........ ...  ................  
........ ...  ..............  
........ .......  
........ ...

........ .......  
........ ...  ................  
........ ...  ..................  
........ ...  .....  
........ .... .......................................... (07FFD7EF91000h)  
........ ...  ........#0xBF8.
........ ...  .....  
........ ...  ......#0xBF8  
........ ..   .................... (07FFD7EE72270h)  
........ ...  ......  
........ ...  ................  
........ ...  ..............  
........ .......  
........ ...

SyntevoAlex · 2024-05-17T19:54:01Z

It can be seen that only a few bytes in the function change. The rest can be verified.

hmartinez82 · 2024-05-17T19:57:44Z

Ok. I'll add a check for the location of the InterlockExchange call (relative to the beginning of the function) instruction That, with the location of the adrp x8 instruction and the location of the ret instruction should be enough?

SyntevoAlex · 2024-05-17T20:05:47Z

I'll add a check for the location of the InterlockExchange call (relative to the beginning of the function)

Not sure what you mean.

To me, it makes sense to validate this part

ldr  w19,[x8,X1]
mov  w1,w0 
add  x0,x8,X2
bl   .................... ................  
mov  w0,w19

Where also X1 == X2

hmartinez82 · 2024-05-20T04:15:01Z

@chirontt Can you give it a try with this latest change?

chirontt · 2024-05-21T02:53:27Z

@chirontt Can you give it a try with this latest change?

It's still working good, i.e. the scrollbars in WoA are still dark:

SyntevoAlex · 2024-05-21T07:20:00Z

In master now, thanks for your contribution.
Today is the last day before the RC1 freeze, and the change only affects barely used arm64 platform, so it should be good.

chirontt · 2024-05-22T02:55:11Z

Thanks @SyntevoAlex , @hmartinez82 for this update. I hope this will keep things smooth for now, until MS decides to spoil the party again.

But I notice that tonight's I-build doesn't contain a recompile of the SWT natives due to this merge. @HannesWell does the automated recompile process require a version increment in order to trigger it?

HannesWell · 2024-05-22T05:33:45Z

Thank you @SyntevoAlex for your help.

But I notice that tonight's I-build doesn't contain a recompile of the SWT natives due to this merge. @HannesWell does the automated recompile process require a version increment in order to trigger it?

No that's not necessary, the build just timed-out/failed. Probably due to heavy load on the build servers due to I-build tests.
I restarted the master build again, the next I-build after it succeeds should contain the recompiled natives.

HannesWell · 2024-05-22T06:11:36Z

Actually the problem is that the rie8t-win11-arm64 node is offline in the RelEng Jenkins instance and that node is used to compile the binaries for win32.aarch64. Created an help-desk issue:
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/4657

HannesWell · 2024-05-22T18:01:45Z

Actually the problem is that the rie8t-win11-arm64 node is offline in the RelEng Jenkins instance and that node is used to compile the binaries for win32.aarch64.

The node is back online and the master build passed before this noon's I-build so it should contain the recompiled binaries:
https://download.eclipse.org/eclipse/downloads/drops4/I20240522-0600/

hmartinez82 requested review from niraj-modi and iloveeclipse as code owners April 13, 2024 20:50

hmartinez82 mentioned this pull request Apr 13, 2024

Handle validation of uxtheme.dll undocumented exported functions in ARM64 builds #1048

Merged

chirontt mentioned this pull request Apr 14, 2024

Native support for Eclipse SDKs on Windows Arm64 eclipse-platform/eclipse.platform.releng.aggregator#577

Open

31 tasks

HannesWell force-pushed the oscommon_aarch64_again branch from 3b8abbf to 5c7ff48 Compare May 8, 2024 18:53

hmartinez82 force-pushed the oscommon_aarch64_again branch from 5c7ff48 to f48138b Compare May 10, 2024 07:53

hmartinez82 changed the title ~~Validate SetPreferredAppMode() in ARM64 with ADRP instruction instead~~ Accept two possible arguments for the ADD opcode on ARM64 validation of SetPreferredAppMode() May 10, 2024

SyntevoAlex changed the title ~~Accept two possible arguments for the ADD opcode on ARM64 validation of SetPreferredAppMode()~~ [win32][arm64] Support Dark Theme on newer Windows builds May 10, 2024

hmartinez82 force-pushed the oscommon_aarch64_again branch from d2baf6d to 18bafe0 Compare May 16, 2024 19:02

hmartinez82 force-pushed the oscommon_aarch64_again branch from 18bafe0 to 3eddacb Compare May 17, 2024 03:22

hmartinez82 force-pushed the oscommon_aarch64_again branch from 3eddacb to 8f418fe Compare May 17, 2024 04:54

hmartinez82 force-pushed the oscommon_aarch64_again branch from 8f418fe to 373e5a9 Compare May 20, 2024 04:14

hmartinez82 force-pushed the oscommon_aarch64_again branch from 373e5a9 to 9255e89 Compare May 20, 2024 04:16

[win32][arm64] Support Dark Theme on newer Windows builds

a0c4d79

hmartinez82 force-pushed the oscommon_aarch64_again branch from 9255e89 to a0c4d79 Compare May 20, 2024 04:23

SyntevoAlex merged commit 8c211ce into eclipse-platform:master May 21, 2024
8 of 10 checks passed

hmartinez82 deleted the oscommon_aarch64_again branch May 21, 2024 07:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[win32][arm64] Support Dark Theme on newer Windows builds #1172

[win32][arm64] Support Dark Theme on newer Windows builds #1172

hmartinez82 commented Apr 13, 2024 •

edited

github-actions bot commented Apr 13, 2024 •

edited

chirontt commented Apr 14, 2024

chirontt commented Apr 14, 2024

HannesWell commented May 8, 2024

SyntevoAlex commented May 9, 2024

hmartinez82 commented May 9, 2024

hmartinez82 commented May 10, 2024

SyntevoAlex commented May 10, 2024

SyntevoAlex commented May 10, 2024

hmartinez82 commented May 10, 2024

chirontt commented May 10, 2024

chirontt commented May 10, 2024

SyntevoAlex commented May 10, 2024

chirontt commented May 10, 2024

SyntevoAlex commented May 16, 2024

SyntevoAlex commented May 16, 2024

chirontt commented May 17, 2024

hmartinez82 commented May 17, 2024 •

edited

hmartinez82 commented May 17, 2024

chirontt commented May 17, 2024

SyntevoAlex commented May 17, 2024 •

edited

hmartinez82 commented May 17, 2024 •

edited

SyntevoAlex commented May 17, 2024

SyntevoAlex commented May 17, 2024

hmartinez82 commented May 17, 2024 •

edited

SyntevoAlex commented May 17, 2024

hmartinez82 commented May 20, 2024

chirontt commented May 21, 2024

SyntevoAlex commented May 21, 2024

chirontt commented May 22, 2024

HannesWell commented May 22, 2024 •

edited

HannesWell commented May 22, 2024

HannesWell commented May 22, 2024

[win32][arm64] Support Dark Theme on newer Windows builds #1172

[win32][arm64] Support Dark Theme on newer Windows builds #1172

Conversation

hmartinez82 commented Apr 13, 2024 • edited

github-actions bot commented Apr 13, 2024 • edited

Test Results

chirontt commented Apr 14, 2024

chirontt commented Apr 14, 2024

HannesWell commented May 8, 2024

SyntevoAlex commented May 9, 2024

hmartinez82 commented May 9, 2024

hmartinez82 commented May 10, 2024

SyntevoAlex commented May 10, 2024

SyntevoAlex commented May 10, 2024

hmartinez82 commented May 10, 2024

chirontt commented May 10, 2024

chirontt commented May 10, 2024

SyntevoAlex commented May 10, 2024

chirontt commented May 10, 2024

SyntevoAlex commented May 16, 2024

SyntevoAlex commented May 16, 2024

chirontt commented May 17, 2024

hmartinez82 commented May 17, 2024 • edited

hmartinez82 commented May 17, 2024

chirontt commented May 17, 2024

SyntevoAlex commented May 17, 2024 • edited

hmartinez82 commented May 17, 2024 • edited

SyntevoAlex commented May 17, 2024

SyntevoAlex commented May 17, 2024

hmartinez82 commented May 17, 2024 • edited

SyntevoAlex commented May 17, 2024

hmartinez82 commented May 20, 2024

chirontt commented May 21, 2024

SyntevoAlex commented May 21, 2024

chirontt commented May 22, 2024

HannesWell commented May 22, 2024 • edited

HannesWell commented May 22, 2024

HannesWell commented May 22, 2024

hmartinez82 commented Apr 13, 2024 •

edited

github-actions bot commented Apr 13, 2024 •

edited

hmartinez82 commented May 17, 2024 •

edited

SyntevoAlex commented May 17, 2024 •

edited

hmartinez82 commented May 17, 2024 •

edited

hmartinez82 commented May 17, 2024 •

edited

HannesWell commented May 22, 2024 •

edited