SUMMARY When trying to open existing photo files on Chrome OS 83 (beta), I get a message saying: "The chosen file's location can not be found. Does it exist?". It does not matter where the file is located. The file picker shows the files (jpg & png). I verified that the Kitra app had storage access. Here is the log file: SESSION: 25 May 2020 11:48:01 -0500. Executing /data/app/org.krita-dmKGE5K2Wb7SEiIfWbU6kA==/lib/x86_64/libkrita.so Krita Version: 4.2.10 (git 1b1513a), Qt version compiled: 5.12.7, loaded: 5.12.7. Process ID: 21525 -- -- -- -- -- -- -- -- 25 May 2020 11:49:37 -0500: CLOSING SESSION STEPS TO REPRODUCE 1. Click on Open File 2. Select a file 3. OBSERVED RESULT Error message: "The chosen file's location can not be found. Does it exist?" EXPECTED RESULT I expect the file to open in kitra SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Thanks for the report. We're trying to find a solution...
*** Bug 422126 has been marked as a duplicate of this bug. ***
Git commit 3cf35fd689d9cfd0ce28775b3ef87cfbdbe669b0 by Sharaf Zaman. Committed on 01/06/2020 at 10:25. Pushed by szaman into branch 'krita/4.3'. Fix the way URIs are handled Prior to this commit, URIs were expected to resolve to some file on Android, but this assumption turned out to be flawed. URIs may or may not resolve. What is expected way of opening a file using them is to either use InputStreams or File Descriptors. Later is being used out of the two. # Conflicts: # libs/ui/KisMainWindow.cpp A +285 -0 3rdparty/ext_qt/0040-Add-file-engine-for-Android-content-URLs.patch A +175 -0 3rdparty/ext_qt/0041-Android-handle-check-permissions-before-any-file-ope.patch A +188 -0 3rdparty/ext_qt/0042-Android-Add-support-for-getting-information-about-co.patch A +57 -0 3rdparty/ext_qt/0043-Also-fall-back-to-direct-write-for-Android-content-U.patch A +29 -0 3rdparty/ext_qt/0044-Andriod-make-URIs-writable.patch M +5 -0 3rdparty/ext_qt/CMakeLists.txt M +23 -1 libs/ui/KisAndroidFileManager.cpp M +4 -1 libs/ui/KisAndroidFileManager.h M +39 -7 libs/ui/KisDocument.cpp M +7 -0 libs/ui/KisDocument.h M +10 -13 libs/ui/KisMainWindow.cpp M +6 -1 libs/ui/KisMainWindow.h M +3 -70 packaging/android/apk/src/org/krita/android/FileUtils.java https://invent.kde.org/graphics/krita/commit/3cf35fd689d9cfd0ce28775b3ef87cfbdbe669b0
Git commit 4019233ceb5ae5eebafd9675d2b2b97a6d9f135d by Boudewijn Rempt, on behalf of Sharaf Zaman. Committed on 01/06/2020 at 14:08. Pushed by rempt into branch 'krita/4.3.0'. Fix the way URIs are handled Prior to this commit, URIs were expected to resolve to some file on Android, but this assumption turned out to be flawed. URIs may or may not resolve. What is expected way of opening a file using them is to either use InputStreams or File Descriptors. Later is being used out of the two. # Conflicts: # libs/ui/KisMainWindow.cpp (cherry picked from commit 3cf35fd689d9cfd0ce28775b3ef87cfbdbe669b0) A +285 -0 3rdparty/ext_qt/0040-Add-file-engine-for-Android-content-URLs.patch A +175 -0 3rdparty/ext_qt/0041-Android-handle-check-permissions-before-any-file-ope.patch A +188 -0 3rdparty/ext_qt/0042-Android-Add-support-for-getting-information-about-co.patch A +57 -0 3rdparty/ext_qt/0043-Also-fall-back-to-direct-write-for-Android-content-U.patch A +29 -0 3rdparty/ext_qt/0044-Andriod-make-URIs-writable.patch M +5 -0 3rdparty/ext_qt/CMakeLists.txt M +23 -1 libs/ui/KisAndroidFileManager.cpp M +4 -1 libs/ui/KisAndroidFileManager.h M +39 -7 libs/ui/KisDocument.cpp M +7 -0 libs/ui/KisDocument.h M +10 -13 libs/ui/KisMainWindow.cpp M +6 -1 libs/ui/KisMainWindow.h M +3 -70 packaging/android/apk/src/org/krita/android/FileUtils.java https://invent.kde.org/graphics/krita/commit/4019233ceb5ae5eebafd9675d2b2b97a6d9f135d
Git commit 2a87a898b5c56243ba13e3a3b76b7957589b60a0 by Sharaf Zaman. Committed on 21/09/2020 at 17:03. Pushed by szaman into branch 'master'. Fix the way URIs are handled Prior to this commit, URIs were expected to resolve to some file on Android, but this assumption turned out to be flawed. URIs may or may not resolve. What is expected way of opening a file using them is to either use InputStreams or File Descriptors. Later is being used out of the two. # Conflicts: # libs/ui/KisMainWindow.cpp A +285 -0 3rdparty/ext_qt/0040-Add-file-engine-for-Android-content-URLs.patch A +175 -0 3rdparty/ext_qt/0041-Android-handle-check-permissions-before-any-file-ope.patch A +188 -0 3rdparty/ext_qt/0042-Android-Add-support-for-getting-information-about-co.patch A +57 -0 3rdparty/ext_qt/0043-Also-fall-back-to-direct-write-for-Android-content-U.patch A +29 -0 3rdparty/ext_qt/0044-Andriod-make-URIs-writable.patch M +5 -0 3rdparty/ext_qt/CMakeLists.txt M +23 -1 libs/ui/KisAndroidFileManager.cpp M +4 -1 libs/ui/KisAndroidFileManager.h M +39 -7 libs/ui/KisDocument.cpp M +7 -0 libs/ui/KisDocument.h M +10 -13 libs/ui/KisMainWindow.cpp M +6 -1 libs/ui/KisMainWindow.h M +3 -70 packaging/android/apk/src/org/krita/android/FileUtils.java https://invent.kde.org/graphics/krita/commit/2a87a898b5c56243ba13e3a3b76b7957589b60a0