-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Moving window handling functions into a safer transition mode #5415
Moving window handling functions into a safer transition mode #5415
Conversation
Avoid the most likely crashes as people try out 2.6
…t the wrong time or recursively
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.
Thanks. Will test this in Rymdport but this was just a quick drive-by review on my phone in the meantime :)
@@ -1,2 +1,4 @@ | |||
// Package build contains information about they type of build currently running. | |||
package build | |||
|
|||
const DisableThreadChecks = false |
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 always false. There is no build tag?
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.
As for a build tag, I'd rather have something like new-threading-model
or maybe using-correct-threads
(or similar) over disable-thread-checks
. The latter sounds a bit negative like you are now using unsafe and might shoot yourself in the foot 😅
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.
Hmm, not sure I agree with that, to me the current name is more clear what it's doing, where the new-threading-model
name suggests it would be enabling something bigger (like if we supported both the old and new threading models together and the app could choose which). And the naming of using-correct-threads
doesn't really suggest what it does at all IMO.
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.
Sorry for the confusion, there is a local TODO in my code maybe i should have left it here ;).
Disabling is a follow up as that is where the naming discussions come in!
go fn() | ||
} | ||
|
||
func EnsureMain(fn func()) { |
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.
I kind of feel like these should have comments as they are exported (although in an internal package but anyway)? Applies to the ones above as well.
@dweymouth @Jacalz thanks for the comments. My aim is to land this code ASAP so developers on this branch get the immediate benefit and we get more testing. |
How would you otherwise do it? I need another way of turning it off for Flatpak compared to FyneApp.toml. What I would propose, like on Slack, is having a build tag that gets set by cmd/fyne when a value in FyneApp.toml is set. |
Thanks for the doc comments. I don't think we need "Since:" for internal packages but you don't have to remove it :) |
The point of following up with another PR is so we can have that discussion - I don't know the answer for sure and want to discuss it. It's pretty clear from people testing develop that we need this - so can we get it added before deciding how and when it can be disabled? |
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.
I'm still in favour of a build tag to disabled this but approved for now as we obviously need that transition for older codebases.
Thanks. I will open the follow-on PR shortly and we can discuss further. |
Avoid the most likely crashes as people try out 2.6
Description:
Progressing #5411
Checklist:
I tested using the following code:
Which worked, but logged this: