Whenever I try to open a file stored on a remote server, Krita simply refuses to see the path as extant. Even when I drop the file into Krita from a file browser application. Also, cannot find gvfs/remote mount points/remote softlinks from Krita's File Open dialogue. It takes a while, copying to local machine just to edit to then have to manually upload back to the fileserver. Can't find any info in FAQ about remote file access issues/protocols. STEPS TO REPRODUCE 1. Open Krita; 2. a) Drop file from remote share into Krita; or b) Click File>Open and browse to /run/user/1000/gvfs...; or c) Click File>Open and browse to link to a gvfs mount point; 3. FAILURE OBSERVED RESULT "The file file:///run/user/1000/gvfs/smb-share:server=[xxxxxx],share=[xxxxxx]/Customer Data/[xxxxxx]/Website photos/Projects/[xxxxxx]/IMG_1713.JPG does not exist." EXPECTED RESULT File should be open ready for editing and saving as normal. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux Mint 19.2 (available in About System) KDE Plasma Version: ?? (Command 'kf5-config' not found) KDE Frameworks Version: ?? (Command 'kf5-config' not found) Qt Version: 5.14.2 ADDITIONAL INFORMATION System: Host: [xxxxxx] Kernel: 4.15.0-96-generic x86_64 bits: 64 compiler: gcc v: 7.5.0 Desktop: Xfce 4.12.3 tk: Gtk 2.24.31 wm: Compiz dm: LightDM Distro: Linux Mint 19.2 Tina base: Ubuntu 18.04 bionic Krita Version: 4.2.9 Languages: en_GB, en, en, en_GB, en Hidpi: true Qt Version (compiled): 5.14.1 Version (loaded): 5.14.2 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.15.0-96-generic Pretty Productname: KDE Flatpak runtime Product Type: org.kde.Platform Product Version: 5.14 OpenGL Info Vendor: "Intel Open Source Technology Center" Renderer: "Mesa DRI Intel(R) HD Graphics (BYT)" Version: "3.0 Mesa 20.0.1" Shading language: "1.30" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false Hardware Information GPU Acceleration: auto Memory: 7430 Mb Number of Cores: 4 Swap Location: /var/tmp Current Settings Current Swap Location: /var/tmp Undo Enabled: 1 Undo Stack Limit: 30 Use OpenGL: 1 Use OpenGL Texture Buffer: 1 Use AMD Vectorization Workaround: 0 Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: 1 Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Use Win8 Pointer Input: 0 Use RightMiddleTabletButton Workaround: 0 Levels of Detail Enabled: 0 Use Zip64: 0 Display Information Number of screens: 2 Screen: 0 Name: HDMI-1 Depth: 24 Scale: 1 Resolution in pixels: 1440x900 Manufacturer: Bit 3 Computer Model: LE1940- Refresh Rate: 74.9844 Screen: 1 Name: VGA-1 Depth: 24 Scale: 1 Resolution in pixels: 1368x768 Manufacturer: Model: Refresh Rate: 59.882
We use Qt to access files, and it does distinguish between local files and remote files... But I see "KDE Flatpak runtime" in the information; are you using a flatpak? Note that flatpaks can restrict access to some areas. Can you please check if appimage has the same issue?
(In reply to Tymond from comment #1) Thank you for your quick response. > We use Qt to access files, and it does distinguish between local files and > remote files... Ah, so was Krita written to ignore/not use remote files? > But I see "KDE Flatpak runtime" in the information; are you using a flatpak? > Note that flatpaks can restrict access to some areas. Can you please check > if appimage has the same issue? It was the version available in the Software Manager in Mint. I usually try to stay away from Flatpacks and Snaps as they don't fit into my chosen desktop/window manager well and are therefore difficult to manage, but Kritsa is a very useful application (aside from this one little oversight.) What is 'appimage'? I am no seasoned expert in Linux, I only know a few distros. :/ Oh, so can I just reconfigure QT or the flatpack framework to allow access/display remote files? Thanks again :)
Mint nowadays don't distinguish (in the Applications Manager) between flatpak versions and regular repository versions. Flatpak is a new form of getting programs to your Linux. I will need to ask someone more knowledgable, but I believe it is possible that your issue comes from how flatpaks are designed and it cannot be worked around unless you will use a different method. Appimage is another way of getting program to your Linux. This is one single file, just like .exe on Windows. You can download it from here: https://krita.org/en/download/krita-desktop/ You need to right-click, go to Permissions and check "Allow executing this file as a program" (or something like that, my Mint is in Polish so I don't know the English phrase). Then you'll be able to just double-click. Every time there is an issue like that we tell users to check the appimage because the appimage is the only form that gets all libraries in the exact same version that Krita uses on Windows and Macs and what is considered "official". For example on Linux it contains some patches for tablets and other things that were written by Dmitry and that are not yet built into the system Qt.
"Mint nowadays don't distinguish (in the Applications Manager) between flatpak versions and regular repository versions." Yes, I find that quite frustrating. "Flatpak is a new form of getting programs to your Linux. I will need to ask someone more knowledgable, but I believe it is possible that your issue comes from how flatpaks are designed and it cannot be worked around unless you will use a different method." I will get rid of this flatpack version, then. Thank you for the heads-up. I now know to stay away from Flatpacks :) "Appimage is another way of getting program to your Linux. This is one single file, just like .exe on Windows." Ah, i think I do remember downloading a .AppImage file for something else. I thought you meant a program called 'AppImage' lol derp me "Allow executing this file as a program" (or something like that, my Mint is in Polish so I don't know the English phrase). Your English is quite perfect :) "Every time there is an issue like that we tell users to check the appimage because the appimage is the only form that gets all libraries in the exact same version that Krita uses on Windows and Macs and what is considered "official". For example on Linux it contains some patches for tablets and other things that were written by Dmitry and that are not yet built into the system Qt." You are most knowledgable - I will give the .AppImage package a go, right now. Thank you so much for the information. It usually takes a lot of trial and error or investigation for me to find these things out. I will let you know how it goes :) Then, most likely close this report down.
I uninstalled the Flatpack to avoid any potential conflicts and downloaded the 'krita-4.2.9-x86_64.appimage' file from the URL you kindly shared. I made it executable, ran it then browsed to my gvfs mount points and was able to navigate my way to my files and open them perfectly fine :) I am over the moon! I copied the .appimage file into a new directory called 'Apps' (who'da thunk of it?) and added a launcher and icon for it and bingo - Back to normal. The last thing was to associate the .AppImage file itself with the filetypes I want to use with Krita. I can now open files directly from my file server without issues :D I am so thankful that it wasn't a problem after all - And that you were so knowledgable about the Flatpacks. I really appreciate the time you took to look into my non-issue :) Take care and thanks again. Oh, should this be marked as 'DOWNSTREAM' or 'NOT A BUG'?
I'll create a bug against the flatpak and change this to downstream.
Looks like the flatpak maintainer is very much on the ball: https://github.com/flathub/org.kde.krita/pull/22/commits/4c2839d9ec12c59f8487a9ad1826fb1781a2b5fe
(In reply to Tymond from comment #3) > I will need to ask someone more knowledgable, > but I believe it is possible that your issue comes from how > flatpaks are designed and it cannot be worked around unless you will use a > different method. If you don't know the details, please don't spread false information. Flatpak is meant to be secure, so it grants as little permissions as possible out of the box. I just add the needed permission to the flatpak and the update should soon be available to all users. (In reply to Stin from comment #5) > I uninstalled the Flatpack to avoid any potential conflicts and downloaded > the 'krita-4.2.9-x86_64.appimage' file from the URL you kindly shared. You don't need to worry about conflicts, flatpak are isolated from the rest of the system.
Good news all round. Thank you, all, for your help :)