[Windows] Resize with windows snapping incorrect

[BenWildeman]

with adding the following to main.cpp:

#include <bitsdojo_window_windows/bitsdojo_window_plugin.h>
auto bdw = bitsdojo_window_configure(BDW_CUSTOM_FRAME | BDW_HIDE_ON_STARTUP);

Resizing through windows snapping (win key + left/right) will be wider and taller than intended, overflowing both left and right and bottom. However, when removing BDW_CUSTOM_FRAME to show the original windows frame, snapping resizes correctly, which means the calculations are off within this package.

[davi-sant]

adicionando o seguinte ao main.cpp:

#include <bitsdojo_window_windows/bitsdojo_window_plugin.h>
auto bdw = bitsdojo_window_configure(BDW_CUSTOM_FRAME | BDW_HIDE_ON_STARTUP);

O redimensionamento através do encaixe de janelas (tecla win + esquerda/direita) será mais largo e mais alto do que o pretendido, transbordando tanto para a esquerda quanto para a direita e para baixo. No entanto, ao remover BDW_CUSTOM_FRAMEpara mostrar o quadro original do Windows, o snap é redimensionado corretamente, o que significa que os cálculos estão incorretos neste pacote.

Hello all right, could you tell me which platform you are having this problem on? I tried to reproduce the error using windows 11, but the app works correctly.

[BenWildeman]

I'm on Windows 11 also. The easiest way to depict this is by using Fancy Zones from PowerToys. I've created a 3 column grid with padding so you can see the overspill. within the video provided, Task Manager, and my browser fit perfectly within the purple outlined column, whereas a newly created blank application is slightly too big for the grid. I've found that maximizing in general is actually too big, not specifically linked to snapping.

[BenWildeman]

In the following screenshot, I've moved the Fancy Zones window above the columns so you can see where the app actually should be sized to

[BenWildeman]

To add to this, I've noticed that the title bar and subsequently the windows buttons are incorrectly sized from native windows applications. The heights of those are off by a few pixels (when drawn, the title bar should be 32px high). I do think this is an issue that's simply been missed, as in the following comment within the code: https://github.com/bitsdojo/bitsdojo_window/blob/9b83939c321caa438da4be598f527f028e0efa5f/bitsdojo_window/lib/src/icons/icons.dart#L15

This isn't actually the case when the correct values for these are used. In essence, the Icons for the buttons should fit within a 10x10px box. for my app, I've hard coded the correct values for the title bar and button size to the correct sizes. as proof, here's a screenshot with two close buttons, the first is my own drawn using the CustomPaint, and the second being the one provided by the package. they're indistinguishable between the two whereas as seen in the code, the author states that the one provided is "crisper".

the reason why I'm mentioning this is because I think this issue outlined within the source code, potentially has the same root cause of the window being incorrectly sized

[davi-sant]

Estou no Windows 11 também. A maneira mais fácil de descrever isso é usando Zonas de fantasia da PowerToys. Eu criei uma grade de 3 colunas com preenchimento para que você possa ver o transbordamento. no vídeo fornecido, o Gerenciador de Tarefas e meu navegador se encaixam perfeitamente na coluna delineada em roxo, enquanto um aplicativo em branco recém-criado é um pouco grande demais para a grade. Descobri que maximizar em geral é realmente muito grande, não especificamente vinculado ao encaixe.

I hadn't tested it using powerToys at first - so I downloaded and tested it and there really is a difference in window size compared to other applications. It is also worth mentioning that it is important to test using a flutter application without the present packege, to see how the window sizes behave.

[BenWildeman]

not using this package, flutter apps behave correctly. EDIT: this package behaves correctly too: https://github.com/leanflutter/window_manager