Add ability to assign a menu when creating a window on Windows #1842
Conversation
The primary reason for doing this here instead of just assigning a menu later on with `SetMenu` is to avoid that `with_inner_size` breaks, since the menu takes up some space that is not taken into account, which means the user would have to use `set_inner_size` again after adding the menu. Notes: - Child windows cannot have a menu, so perhaps this should be represented typewise? - Dark mode doesn't look good with win32 menus, unfortunately not fixable, see ysc3839/win32-darkmode#1
msiglreith
added
DS - windows
C - waiting on maintainer
src/platform_impl/windows/mod.rs
Outdated
| @@ -17,7 +17,9 @@ use crate::window::Theme; | |||
|
|
|||
| #[derive(Clone)] | |||
| pub struct PlatformSpecificWindowBuilderAttributes { | |||
| // TODO: parent and menu are mutually exclusive; a child window cannot have a menu! | |||
There was a problem hiding this comment.
This should be added the with_menu documentationa and I would say a warn during the creation if that case is hit would be enough
|
Done. Should I do a rebase? It also occurs to me, both Also, |
Thanks - no, we squash-merge here :D
Agree, but I think that's a different issue right now, I would like to handle this separately. There is also an open issue regarding exposing typedefs like
The current name looks totally fine to me! |
cargo fmthas been run on this branchcargo docbuilds successfullyCHANGELOG.mdif knowledge of this change could be valuable to usersAdded
WindowBuilderExtWindows::with_menu.The primary reason for doing it here instead of just assigning a menu later on with
winapi::um::winuser::SetMenuis to avoid thatwith_inner_sizebreaks, since the menu takes up some space that is not taken into account, which means the user would have to useset_inner_sizeagain after adding the menu.This, I'm guessing, could cause a jarring effect for the user (that the window resizes when starting).
Unresolved:
Child windows cannot have a menu, so perhaps this should be represented typewise?