sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: "add_child" does not work in @exported_storage node
Labels: bug,topic:gdscript

### Tested versions

v4.3.stable.official

### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 560.94) - AMD Ryzen 5 5600X 6-Core Processor 3.70 GHz

### Issue description

When creating a plugin, you can't use the "add_child" function inside a script in a "export_storage" node, but when recreating this same behavior with the "export" annotation, it works as intended.

For more information, check [this video](https://youtu.be/EDXZsPf4Gpk), where I created a MRP explaining my problem

### Steps to reproduce

I have made a MRP to help you all to see what I mean, but here is the steps to reproduce the problem.
- 1. Clone [the MRP project](https://github.com/GustavoLR548/testeexportedstorage) and open the project in Godot 4.3 official.
- 2. Open the ```CenaTeste.tscn```
- 3. Instantiate the ```SpriteSpawnerHolder.tscn``` as a child scene of the root node of the scene ```CenaTesteExportedStorage```
- 4. Then instantiate the ```SpriteSpawner.tscn``` as a child scene of the ```SpriteSpawnerHolder.tscn```
- 5. Your scene should look something like this.
![image](https://github.com/user-attachments/assets/5f0489a6-9599-4c3f-818e-6464175b9512)
- 6. Now run the project and see that Sprite did not spawn
![image](https://github.com/user-attachments/assets/1b668988-ab86-4e00-8f9f-0088725d9f52)
- 7. To "fix" this, go the "addons/meuplugin/SpriteSpawnerHolder.gd" and change the "export_storage" annotation to "export"
![image](https://github.com/user-attachments/assets/5576f8d9-cfab-4b08-8e45-027d17189ee4)
- 8. Clean the ```CenaTeste.tscn``` and repeat steps 2 to 4.
- 9. Now the sprite is spawned as intended:
![image](https://github.com/user-attachments/assets/70df1f79-5c98-408f-8c72-64c9a860d462)



### Minimal reproduction project (MRP)

https://github.com/GustavoLR548/testeexportedstorage
Repository: go
Issue: build: build failure on gotip-openbsd-ppc64
Labels: NeedsInvestigation

```
#!watchflakes
default <- builder == "gotip-openbsd-ppc64" && repo == "go" && mode == "build"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8738980008328495489)):

    [I2024-08-21T16:58:34.824062Z 99816 0 sink.go:276] SinkServer: warm-up started
    [I2024-08-21T16:58:34.824127Z 99816 0 sink.go:346] SinkServer: starting HTTP server...
    [I2024-08-21T16:58:34.826550Z 99816 0 sink.go:281] SinkServer: warm-up ended
    [I2024-08-21T16:58:34.826962Z 99816 0 cmd_stream.go:492] rdb-stream: starting the test command - ["/home/swarming/.swarming/w/ir/cache/tools/bin/result_adapter" "go" "-v=false" "-dump-json" "/home/swarming/.swarming/w/ir/x/w/dist.testjson" "--" "/home/swarming/.swarming/w/ir/x/w/goroot/bin/go" "tool" "dist" "test" "-json"]
    2024/08/21 17:23:37 Failed: exit status 1
    go tool dist: FAILED
    ok  	archive/tar	0.655s
    ok  	archive/zip	2.579s
    ok  	bufio	0.334s
    ok  	bytes	1.491s
    ...
    Warning: no '=' in invocation-link-artifacts pair: "", ignoring
    [I2024-08-21T17:25:25.318762Z 99816 0 cmd_stream.go:488] rdb-stream: the test process terminated
    [I2024-08-21T17:25:25.319406Z 99816 0 sink.go:371] SinkServer: shutdown started
    [I2024-08-21T17:25:25.319512Z 99816 0 sink.go:349] SinkServer: HTTP server stopped with "http: Server closed"
    [I2024-08-21T17:25:25.319577Z 99816 0 sink_server.go:96] SinkServer: draining TestResult channel started
    [I2024-08-21T17:25:26.142964Z 99816 0 sink_server.go:98] SinkServer: draining TestResult channel ended
    [I2024-08-21T17:25:26.143008Z 99816 0 sink_server.go:100] SinkServer: draining Artifact channel started
    [I2024-08-21T17:25:26.384335Z 99816 0 sink_server.go:102] SinkServer: draining Artifact channel ended
    [I2024-08-21T17:25:26.384372Z 99816 0 sink.go:374] SinkServer: shutdown completed successfully
    [I2024-08-21T17:25:26.384405Z 99816 0 cmd_stream.go:420] rdb-stream: exiting with 1


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: pytorch
Issue: Compiled autograd set_logs tests shouldn't use logs_to_string
Labels: triaged,oncall: pt2,module: compiled autograd

### 🐛 Describe the bug

logs_to_string's context manager already enables the logger, so set_logs is probably being ignored

### Versions

main

cc @ezyang @chauhang @penguinwu
Repository: PowerToys
Issue: Advanced Paste - Paste as RGB
Labels: Needs-Triage

### Description of the new feature / enhancement

Advanced Paste should allow for hex color values to be pasted into the default Windows color picker. The hex value would be converted to three separate pastes into the three separate RGB input boxes. User would paste into the "R" box and the "G" and "B" boxes would subsequently be filled.

### Scenario when this would be used?

This would be useful for any application that still restricts users to an RGB color choice. It's a inconvenience to try to remember the three RGB values selected from the color picker, and it would be much more useful to allow users to just paste it in.

### Supporting information

This is a problem that doesn't seem to have an easy solution. I found that [most forum posts](https://superuser.com/questions/1412770/how-to-change-the-windows-10-default-color-picker) now point to a piece of deprecated software called "Jovian," which was able to override the default behavior of opening up the Windows API ChooseColor function.
Repository: pytorch
Issue: LoweringException: NotImplementedError: inductor does not support pin_memory
Labels: triaged,oncall: pt2,module: inductor

### 🐛 Describe the bug

## Repro:
1. Enable the test by commenting out: https://github.com/pytorch/pytorch/blob/8604c0a150b12e0ba3f9a6faaf52498370f21368/test/inductor/test_compiled_autograd.py#L2489
2. `python test/inductor/test_compiled_autograd.py TestAutogradWithCompiledAutograd.test_graph_save_on_cpu` 

## Example graph node
```python
empty: "f32[5][1]cpu" = torch.ops.aten.empty.memory_format([sym_size_int], dtype = torch.float32, layout = torch.strided, device = device(type='cpu'), pin_memory = True);
```

## Error:
```
  File "/data/users/xmfan/a/pytorch/torch/_dynamo/output_graph.py", line 1465, in _call_user_compiler
    raise BackendCompilerFailed(self.compiler_fn, e) from e
torch._dynamo.exc.BackendCompilerFailed: backend='_inner_compiler' raised:
LoweringException: NotImplementedError: inductor does not support pin_memory
  target: aten.empty.memory_format
  args[0]: [5]
  kwargs: {'dtype': torch.float32, 'layout': torch.strided, 'device': device(type='cpu'), 'pin_memory': True}
```



### Versions

main

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire
Repository: rust
Issue: Closure Fn* trait coercion removes other implementable Fn* traits
Labels: C-bug,T-types

I tried this code:

```rust
fn demo<F: FnOnce()>(f: F) -> F { f }

fn other<F: Fn()>(_f: F) {}

fn main() {
    let x = || ();
    other(x); 
    
    let x = demo(|| ());
    other(x); 
}
```

I expected to see this happen: The code to compile.

Instead, this happened: Compilation failed stating the second `x` does not implement `Fn`.
```rs
error[E0525]: expected a closure that implements the `Fn` trait, but this closure only implements `FnOnce`
  --> src/main.rs:9:18
   |
9  |     let x = demo(|| ());
   |                  ^^ this closure implements `FnOnce`, not `Fn`
10 |     other(x); 
   |     ----- - the requirement to implement `Fn` derives from here
   |     |
   |     required by a bound introduced by this call
   |
note: required by a bound in `other`
  --> src/main.rs:3:13
   |
3  | fn other<F: Fn()>(_f: F) {}
   |             ^^^^ required by this bound in `other`
```
[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bb5d8f332311ca9624267f44d890ea94)

I would expect this to either compile fine (which means changing something about how closure coercion works) or for the diagnostic given to point at the coercion to a `FnOnce` for the reason why it doesn't implement the `Fn` trait.

### Meta

`rustc --version --verbose`:
```
rustc 1.80.1 (3f5fd8dd4 2024-08-06)
binary: rustc
commit-hash: 3f5fd8dd41153bc5fdca9427e9e05be2c767ba23
commit-date: 2024-08-06
host: x86_64-unknown-linux-gnu
release: 1.80.1
LLVM version: 18.1.7
```
Repository: pytorch
Issue: [export] Incorrect behavior with torch.LongTensor and torch.Tensor 
Labels: triaged,oncall: export

### 🐛 Describe the bug

It seems like if a user calls `torch.LongTensor` or `torch.Tensor` within a program, export creates a tensor constant that is a FakeTensor, not the actual tensor constant. This applies to both strict and non-strict export.

```python
    def test_longtensor(self):
        class M(torch.nn.Module):
            def forward(self, x):
                return (x + torch.LongTensor(1),)
        
        inp = (torch.tensor(3),)
        
        ep = torch.export.export(M(), inp)
        print(ep.graph)
        """
        graph():
            %c_lifted_tensor_0 : [num_users=1] = placeholder[target=c_lifted_tensor_0]
            %x : [num_users=1] = placeholder[target=x]
            %add : [num_users=1] = call_function[target=torch.ops.aten.add.Tensor](args = (%x, %c_lifted_tensor_0), kwargs = {})
            return (add,)
        """"
        print(ep.constants)
        """
        {'lifted_tensor_0': FakeTensor(..., size=(1,))}
        """
        print(ep.module()(*inp))
        """
        (FakeTensor(..., size=(1,)),)
        """
```
However this doesn't seem to repro when you call make_fx or aot_export_module directly.

The workaround is simple -- just replace it with `torch.tensor` or `torch.full` -- but this behavior seems incorrect.


Internal reference: https://fb.workplace.com/groups/1075192433118967/permalink/7711495418978293/

### Versions

main

cc @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @suo @ydwu4 @penguinwu
Repository: react
Issue: [Compiler Bug]: eslint-plugin-react-compiler errors when updating initialization of ref.current
Labels: Type: Bug,Status: Unconfirmed,Component: Optimizing Compiler

### What kind of issue is this?

- [ ] React Compiler core (the JS output is incorrect, or your app works incorrectly after optimization)
- [ ] babel-plugin-react-compiler (build issue installing or using the Babel plugin)
- [X] eslint-plugin-react-compiler (build issue installing or using the eslint plugin)
- [ ] react-compiler-healthcheck (build issue installing or using the healthcheck script)

### Link to repro

https://playground.react.dev/#N4Igzg9grgTgxgUxALhAHRFMCAEcA2AlggHYAuGA3GiTYQLYAOEMZOwOWCASggGY4Avjj4wI9HBhgIAhnAohqtEnAgkwbAKoA5AJJ6AKroCCAGV0AtAKIARHAF4cAZQCe9AEYR8ACgw79ukZmlrYYAJRKNAgAHsyseGoanNgA8iq4jgA8BgA0AHzehCSEZIQy+ABq5VAIyDgGOAA+ON7eYQ559WHt9p3ANDgJ6mzSAo5cvAKZ9U04ZC6MCBAC-oYm5tZ2nd6rgeshNhE0AziEAt6jAHRwsNLkDvaOu0Ebtu39JIODVzcwd2yOeaLZanYqlcpVfA1B6ODB8KAqUpqDA4AD8oJKZUq1QQbRwdSKmIhOKUg0Ex0+OGkZFgnx+t1IZCUgkiJBicTYABN+DIoPg2PDEYQ1DgALIuYyMRh4j7fBA0mCfTKcwgANzyAAkEPh8BAcAB1Fj4TmZAD0KvVzJoIEEQA

### Repro steps

1. Initialize `useRef` with some dummy value (e.g. null, Symbol, undefined, etc.) to be changed after initialization/during render.
2. Update `ref.current` by checking whether it is equivalent to its initial condition (as per documentation: [useRef#Avoiding recreating the ref contents](https://react.dev/reference/react/useRef#avoiding-recreating-the-ref-contents))
  - > To solve it, you may initialize the ref like this instead:
  ```
  function Video() {
    const playerRef = useRef(null);
    if (playerRef.current === null) {
      playerRef.current = new VideoPlayer();
    }
    // ...
  ```

  - > Normally, writing or reading ref.current during render is not allowed. However, it’s fine in this case because the result is always the same, and the condition only executes during initialization so it’s fully predictable.
  
3. eslint-plugin-react-compiler gives error

```
InvalidReact: Ref values (the `current` property) may not be accessed during render. (https://react.dev/reference/react/useRef)
```

### How often does this bug happen?

Every time

### What version of React are you using?

19.0.0-rc-1d989965-20240821
Repository: PowerToys
Issue: PowerRename - allow references to file metadata in rename
Labels: Needs-Triage

### Description of the new feature / enhancement

When renaming a file, allow extended file properties to be used, such as Author, Location, Device. This could be particularly useful for images with EXIF properties

### Scenario when this would be used?

Changing image names to include more meaningful information

### Supporting information

_No response_
Repository: terminal
Issue: Title bar draw problem next to close button
Labels: Resolution-External,Issue-Bug,Needs-Triage,Needs-Attention

### Windows Terminal version

1.20.11781.0

### Windows build number

10.0.22631.4037

### Other Software

_No response_

### Steps to reproduce

Note: This is intermittent.

1. Open up Windows Terminal.
2. Change focus from another program like Edge and back to Windows Terminal. The most reliable way is to click on the tab on Windows Terminal.
3. See title bar is not acrylic except for small portion to the right of the close button (see attached).
4. If problem does not happen, change focus back to Edge and repeat steps 2-4.

![2024-08-21](https://github.com/user-attachments/assets/da9a18da-1908-4857-a20b-1a0f614203e4)


### Expected Behavior

I expected the acrylic to be consistent.

### Actual Behavior

Acrylic title bar sometimes does not render. I also see it blinking sometime when focus is changed.
Repository: pytorch
Issue: storage_module && PyModule_Check(storage_module) INTERNAL ASSERT FAILED at DynamicTypes.cpp
Labels: module: error checking,triaged,module: python frontend,module: edge cases

### 🐛 Describe the bug

If I run a PyTorch code for the first time using the `eval` function and the built-in functions are restricted, then an internal assertion failure occurs.

```python
import torch
eval("torch.Tensor([1.0])", {"__builtins__": {}, "torch": torch})
```

```
Traceback (most recent call last):
  File "/foo/test.py", line 2, in <module>
    eval("torch.Tensor([1.0])", {"__builtins__": {}, "torch": torch})
  File "<string>", line 1, in <module>
RuntimeError: storage_module && PyModule_Check(storage_module) INTERNAL ASSERT FAILED at "/Users/runner/work/pytorch/pytorch/pytorch/torch/csrc/DynamicTypes.cpp":71, please report a bug to PyTorch. 
```

The problem does not occur if the same code was called once before running them in the `eval` function.

```python
import torch
torch.Tensor([1.0])
eval("torch.Tensor([1.0])", {"__builtins__": {}, "torch": torch})
# no errors
```

This is where the exception occurs:
https://github.com/pytorch/pytorch/blob/v2.4.0/torch/csrc/DynamicTypes.cpp#L71

It seems that`PyImport_ImportModule("torch.storage")` failed because `PyImport_Import` invokes the `__import__()` function from the builtins of the current globals, and `__import__()` is not available in the current globals.

This is understandable from a developer's point of view.  On the other hand, from the user's point of view, I feel that lazy loading is an implementation detail and it would be nice to behave as if everything was loaded when `import torch` is called outside of the `eval`.


### Versions


```
PyTorch version: 2.4.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.6.6 (arm64)
GCC version: Could not collect
Clang version: 15.0.0 (clang-1500.0.40.1)
CMake version: version 3.29.3
Libc version: N/A

Python version: 3.11.3 (main, Jul  9 2023, 00:08:27) [Clang 13.0.0 (clang-1300.0.29.30)] (64-bit runtime)
Python platform: macOS-13.6.6-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1

Versions of relevant libraries:
[pip3] numpy==2.1.0
[pip3] torch==2.4.0
[conda] Could not collect
```

cc @malfet @albanD
Repository: go
Issue: build: build failure on go1.22-linux-amd64_c3h88-perf_vs_release
Labels: NeedsInvestigation

```
#!watchflakes
default <- builder == "go1.22-linux-amd64_c3h88-perf_vs_release" && repo == "go" && mode == "build"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8739607856245328881)):

    go: downloading github.com/BurntSushi/toml v1.0.0
    go: downloading github.com/kballard/go-shellquote v0.0.0-20180428030007-95032a82bc51
    2024/08/14 17:48:04 Load average: 7.47 2.95 1.07 1/999 34087
    2024/08/14 17:48:04 Waiting for load average to drop below 0.20...
    2024/08/14 17:48:34 Load average: 4.53 2.67 1.03 2/1000 34088
    2024/08/14 17:48:34 Waiting for load average to drop below 0.20...
    2024/08/14 17:49:04 Load average: 2.74 2.41 1.00 1/1000 34088
    2024/08/14 17:49:04 Waiting for load average to drop below 0.20...
    2024/08/14 17:49:34 Load average: 1.66 2.18 0.97 2/1000 34088
    2024/08/14 17:49:34 Waiting for load average to drop below 0.20...
    ...
    [sweet] Running benchmark markdown for baseline: run 10
    [sweet] Setting up benchmark: tile38
    Cloning into '/home/swarming/.swarming/w/ir/x/t/go-sweet1404251343/work/tile38/src'...
    remote: Internal Server Error
    fatal: unable to access 'https://github.com/tidwall/tile38/': The requested URL returned error: 500
    [sweet] error: retrieving source for tile38: exit status 128
    [sweet] error: failed to execute benchmarks, see log for details
    2024/08/14 23:20:16 Error running sweet: error running sweet run: exit status 1
    2024/08/14 23:20:16 FAIL
    exit status 1


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: ant-design
Issue: 希望 Form.Item 添加一个 transform 功能，onFinish 时能进行数据转换
Labels: Inactive,unconfirmed

### What problem does this feature solve?

前提：不在初始化时和 onFinish 里单独处理数据。

为什么不想在初始化时和 onFinish 里单独处理数据？
因为每个地方都要单独处理很麻烦，这样可以封装成通用组件，在组件里单独处理数据转换逻辑。
例如：
```
<FormItemDatePicker formItemProps={{}} datePickerProps={{}}  />
```

例子1:
1.打开编辑页，请求详情数据，获得的格式是 ISO 格式，设置进表单
2. 直接提交，这时候提交的是 ISO 格式，但是后端需要 YYYY-MM-DD HH:mm:ss 格式，因为没有对 Picker 进行操作，所以没触发 normalize，导致提交的还是 ISO 格式
```
<Form.Item
  getValueProps={(val) => ({
     value: val ? dayjs(val) : undefined,
   })}
   // 不对 Picker 进行操作，就不会触发
   normalize={(val) => (val ? val.format('YYYY-MM-DD HH:mm:ss') : undefined)}
>
   <DatePicker showTime />
</Form.Item>
```

例子2:
文件上传，getValueFromEvent 需要将 percent 和 status 返回，否则文件状态和进度条会有问题。这样提交时就会这两个参数也一起提交，造成多余的请求参数。

```
<Form.Item
   getValueProps={e => ({
       ......  // 省略
   })}
   getValueFromEvent={e =>  {
     const fileList = Array.isArray(e) ? e : e.fileList;
     return fileList.map(i => ({
        ......,  // 省略
        percent: i.percent,
        status: i.status
     }))
   }}
>
   <Upload />
</Form.Item>
```

### What does the proposed API look like?

现状使用 normalize 基本必须配合 getValueProps 使用，这样是双向的，并且 normalize 初始化不会触发就会有例子1的问题。

添加一个 transform 方法，只有在 onFinish 时会自动转换数据。类似 ProTable 中筛选的 transform

```
<Form.Item transform={value => ...  } />
```



<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: PowerToys
Issue: Awake does not reset time to full time if a different countdown is chosen
Labels: Idea-Enhancement,Product-Awake

### Microsoft PowerToys version

0.83.0

### Installation method

PowerToys auto-update, Microsoft Store

### Running as admin

No

### Area(s) with issue?

Awake

### Steps to reproduce

Set awake time for an interval like 2 hours.  Come back in 90 minutes (before time expires) and set it for 3 hours because you want to extend the awake time.  The awake timer goes to sleep either 30 minutes later (after original 90 minutes) or perhaps in another 90 minutes.  It doesn't extend the time to 3 hours from now when you've reset a new time to keep awake.

Also disabling the switch control for awake and re-enabling it does uncertain things and doesn't always seem to reset the timer.

### ✔️ Expected Behavior

I would expect the UX for awake to make the operation clearer.

- Make it clear when an awake timer is *actually starting."
- Although it's streamlined not to have "Apply" or "OK" buttons, their absence doesn't help to know when a new awake timer has been set, when that timer is starting and when it's ending.
- It's very unclear after changing an awake timer to a new time interval what is actually happening.  Is the time interval still from the original time you set and it doesn't reset the timer? Is the interval from *now* when you just changed the timer to something different? Does turning awake on and off actually clear out previous settings so you know when to expect the timer to expire?
  - I'd argue that any changed values for an awake timer value should reset the timer to 0 and start it again as most timer/stopwatch apps work this way (look at most phones, smart watches and kitchen timers for common expectations--most make you stop the original timer and start a new one in order to change a countdown time).
  - I could understand an argument that you can change the interval without resetting the timer (though I don't think it's a common paradigm for most timers people are familiar with).
  - In either case, the result of modifying the time interval on a timer needs to be clearer. Adding some indication of a new countdown time or an expiration time would at least make things clearer and could also be handy if someone needs to know what to expect.

### ❌ Actual Behavior

Resetting the Awake timer to a different value doesn't seem to reset things in a way that is expected and it's not clear what to expect when changing a timer.  It's unclear when a timer is reset vs extended, if disabling and re-enabling awake resets the timer and how much time is left on an awake interval countdown.

### Other Software

_No response_
Repository: PowerToys
Issue: [PowerToys Run] the window goe out of the screen (+DPI bug)
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.83.0

### Installation method

PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

1. Clear the previous query on opening should be off
2. Maximum number of results before scrolling value should be big enough
3. launch PowerToys Run
4. type somethings would get many results
5. close PowerToys Run
6. relaunch PowerToys Run

### ✔️ Expected Behavior

the window is still in the screen

### ❌ Actual Behavior

the entire or part of window goes out of the screen until delete the typed and can't accessible

https://github.com/user-attachments/assets/394baf61-d117-496f-9ced-8439a94b333e

it didn't happen before acrylic update. why it's broken?

---

![image](https://github.com/user-attachments/assets/4579bc8e-9462-4cf1-ae5f-f5156c7934d8)

![image](https://github.com/user-attachments/assets/604ec4ce-d1a1-46d7-9a8f-66c0cbeddde7)

and bonus DPI bug that I just found

but it's Windows's known issue not PowerToys's fault

https://github.com/user-attachments/assets/4749a311-1d10-468a-bb66-9d0cb9711635

yes that's cool

because mac-like DPI management system is very deadly hardly difficult work

it's bad sad news

but if the off-screen bug is fixed, the DPI bug will be also prevented

### Other Software

zooming effect in video is https://github.com/sanketkheni01/Windows-11-Virtual-desktop-animation but not related