-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document changing the window's resizable status at runtime #84886
Conversation
Calinou
commented
Nov 14, 2023
- This closes ProjectSetting set "display/window/size/resizable" does not take effect #84876.
758f4d1
to
d6768a1
Compare
@@ -810,7 +810,9 @@ | |||
Main window can't be focused. No-focus window will ignore all input, except mouse clicks. | |||
</member> | |||
<member name="display/window/size/resizable" type="bool" setter="" getter="" default="true"> | |||
Allows the window to be resizable by default. | |||
If [code]true[/code], allows the window to be resizable by default. | |||
[b]Note:[/b] This property is only read when the project starts. To change whether the window is resizable at runtime, set [member Window.unresizable] instead on the root Window, which can be retrieved using [code]get_viewport().get_window()[/code]. [member Window.unresizable] takes the opposite value of this setting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is true for pretty much any project setting (at least window releated).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_window()
is available in base Node
, like get_viewport()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what should we do here? It seems a bit weird indeed to flag it specifically here when it applies to all other similar settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what should we do here? It seems a bit weird indeed to flag it specifically here when it applies to all other similar settings.
The policy until now has been to add this note to every project setting where relevant (as some do have an affect when change at runtime). I agree it gets repetitive, but until we get a macro system for documentation, I'm not sure how we can avoid this while ensuring the documentation is as informative as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's go with this as is then as those are often changed settings.
We could maybe look into having something like EDITOR_DEF_RST
for project settings, that add a metadata that this project setting requires restart to be taken into account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could maybe look into having something like
EDITOR_DEF_RST
for project settings, that add a metadata that this project setting requires restart to be taken into account.
Sounds good, but we need a way to point to an equivalent property that can be changed at runtime then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm right, then doing it manually might still be the best option.
Thanks! |
Cherry-picked for 4.2.2. |
Cherry-picked for 4.1.4. |