-
-
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
Avoid double handling of rename in the file system dock #91112
Conversation
Apparently there is another regression 🤔 Closing name edit with Escape will accept it. It's the same before this PR though, but not in dev5. |
f43bcb9
to
a60179b
Compare
Fixed. In the end, some not-very-elegant check has been needed. At least, it's based on an action and not on specific keys. I guess it's good enough until the time where this all is implemented as as first-class feature. |
Renaming in tree mode is now broken. |
a60179b
to
9f34996
Compare
Pushed with a different approach. (Please see the added note to the PR description.) |
d2d9dc2
to
141d2e8
Compare
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.
Seems to work correctly now, tested on Windows.
Thank you very much for your continuous help testing this! |
55b3093
to
fb30c1f
Compare
Can be rebased to avoid the confusion of including two commits when one is already in |
fb30c1f
to
eb2bd41
Compare
Thanks! |
Fixes #90473.
Bugsquad edit: Fixes #91648
In that issue, certain change in
DisplayServerWindows
seems to be the cause of the issue on Windows. However, the report is about Linux. The fact that the issue is cross-platform makes sense if you think about what this PR does.The floating text box used for rename can be confirmed via closing the popup containing it or via actually confirming the input. Since the latter involves the former, there's some code to avoid handling the user will twice. However, it's such a brittle deambiguation mechanism; namely, if certain keys are down, we assume the text input was already handled. It only makes sense that such a handling is subject to break with subtle changes in input event management across display servers. In fact, that's the problem: the rename operation is attempted twice because the current mechanism fails to block the second event.
This PR reimplements the involved handlers in a more robust way so the issue is gone and very unlikely to inadvertedly reappear again. That said, I'm not super happy with how ad hoc this is even in the new version. Maybe
LineEdit
could have a property, such assubmit_on_parent_close
that makes the intended behavior an opt-in feature of it. This PR fixes the issue in the meantime anyway.Lastly,
Tree
seems to have a similar deambiguation code, but that one seems to still work with the currentDisplayServer
implementations. That said, it'd warrant similar love. (CC @bruvzg, that may want to review this PR and later improve the state of affairs.)2024-05-01: This is now based on #91361, which fixes the underlying issue on Windows. However, sine this issue was not Window-specific and I'd still want to have a more solid mechanism here, I've reworked this PR doing so.