Fix "Open destination folder" on macOS #17305
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
it already provides absolute path, no additional manipulations are required.
Chocobo1
previously approved these changes
Jul 2, 2022
glassez
reviewed
Jul 2, 2022
glassez
changed the title
Thank you for the fix! macOS related code, apparently, has not been changed/fixed due to the fact that it remains behind the scenes when developing on other platforms. |
In some unknown way, the one line in Objective-C affects Qt's main loop causing the crash in QApplication::exec() on processing next event after that call. Even crash doesn't happen exactly after this call, it will happen on application exit. Call stack and disassembly are the same in all cases. But running that code in another thread solves the issue.
Chocobo1
approved these changes
Jul 3, 2022
glassez
reviewed
Jul 3, 2022
| @@ -106,7 +106,15 @@ void openFiles(const PathList &pathList) | |||
| for (const auto &path : pathList) | |||
| [pathURLs addObject:[NSURL fileURLWithPath:path.toString().toNSString()]]; | |||
|
|
|||
| [[NSWorkspace sharedWorkspace] activateFileViewerSelectingURLs:pathURLs]; | |||
There was a problem hiding this comment.
Since this is a Qt related issue maybe try to solve it without touching macOS related code (which is still correct)? I mean something like invoking openFiles using queued invocation?
There was a problem hiding this comment.
initially I did. but openFiles() is used in multiple places, so decided to add workaround exactly inside that function
glassez
approved these changes
Jul 3, 2022
|
@Kolcha Also this should be back port to v4.4.x |
Merged
Chocobo1
pushed a commit
to Chocobo1/qBittorrent
that referenced
this pull request
Jul 5, 2022
In some unknown way, the one line in Objective-C affects Qt's main loop causing the crash in QApplication::exec() on processing next event after that call. Even crash doesn't happen exactly after this call, it will happen on application exit. Call stack and disassembly are the same in all cases. But running that code in another thread solves the issue. Original PR: qbittorrent#17305.
Chocobo1
pushed a commit
that referenced
this pull request
Jul 6, 2022
In some unknown way, the one line in Objective-C affects Qt's main loop causing the crash in QApplication::exec() on processing next event after that call. Even crash doesn't happen exactly after this call, it will happen on application exit. Call stack and disassembly are the same in all cases. But running that code in another thread solves the issue. Original PR: #17305.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
actually 2 issues where fixed (see commit messages for details):
Torrent::contentPath()already returns correct abolute path to the torrent content, it considers any possible situationsexisting code tried to append some "prefix" and that lead to not existing "slightly duplicated" path like
so destination folder was not opened in any case (but no crash happens in such case)
crash was not actually fixed, its source somewhere deep in Qt, just some workaround added, see corresponding comment in the code.
build was tested on both MacBooks: Intel-based (Core i9, 2019) and M1-based (M1 Pro, 2021)
Fixes #17273