rust-windowing
On Windows, Add `HitTest` event
- [X] Tested on all platforms changed
- [X] Added an entry to
CHANGELOG.mdif knowledge of this change could be valuable to users - [X] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
- [X] Created or updated an example program if it would help users understand this functionality
- [ ] Updated feature matrix, if new features were added or implemented
Ref: #2413
I have a general question of what is the use for this sort of API? From what I see right now it seems like the user shouldn't care if the X button was clicked, since they have no control over it anyway? Why could you know that the border was pressed or it's windows specific and you want to filter out the events?
At tauri we will only use this event for tauri-egui crate so we can make undecorated window resizable using the mouse. There is another way to do it by using the API proposed in https://github.com/rust-windowing/winit/pull/2003 (we are actually doing that in wry crate by passing cursor location from js) but it has a disadvantage, you can't support snap layout using it or at least my last attempt was unsuccessful.
My understanding of undecorated window handling wrt resizes is that you manually decide on them and resize with. So basically #2003.
you can't support snap layout using it or at least my last attempt was unsuccessful.
I'd assume you mean tiling to regions? Not sure what it means otherwise. From my understanding tiling to edges should be done by the system compositor and not the window. If you don't want to resize past the monitor boundaries you can likely check that during resize, but I'm not sure how you're limited here on windows.
Snap layout is a Windows 11 feature, see https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/apply-snap-layout-menu specifically win32 solution in How do I fix it section. The window manager does handle the snapping but the snap layout UI won't show unless you respond to WM_NCHTITTEST with HTMAXBUTTOM
The window manager does handle the snapping but the snap layout UI won't show unless you respond to WM_NCHT ITTEST with HTMAXBUTTOM
Shouldn't winit do this under the hood without exposing the event to the user directly?
The snap layout UI will automatically work for decorated window but when decorations is disabled, winit can't know where is the maximize button, maybe there is no custom maximize button at all.
Can't you create windows specific api for that or it really requires an event? The application could tell winit where the button is or something like that.
It is possible to add an api to let winit store the button coordinates and size and internally handle that but you'd miss out on free resize and drag handling unless winit handles resizing too internally, which iirc wasn't desirable last time I checked.
It is possible to add an api to let winit store the button coordinates and size and internally handle that but you'd miss out on free resize and drag handling unless
winithandles resizing too internally, which iirc wasn't desirable last time I checked.
Hi, I'm trying to replicate the behavior used by Electron with titlebarOverlay as described here.
This is a pretty handy customization options used by many popular apps and would be amazing to have it implemented here.
EDIT: seems like electron draws the buttons from scratch. But they still go over a HitTest to provide resizing and snap layout behavior
EDIT2: found more reference code from a Tauri fork here
Will this be merged ? undecorated window resizing seems to only be doable well though the hit test event !
We're in need of this as well, I've created a rebased version of this PR here: https://github.com/Traverse-Research/winit/tree/window-area-writer
We'd like to see this merged to main as well, as we're drawing custom decorations.
