| Summary: | Files do not load when files are opened using drag and dropped (shows error message) | ||
|---|---|---|---|
| Product: | [Applications] kgeotag | Reporter: | BOF <bugs_kde_org.5.kuru> |
| Component: | General | Assignee: | Tobias Leupold <tl> |
| Status: | RESOLVED DOWNSTREAM | ||
| Severity: | normal | CC: | tl |
| Priority: | NOR | ||
| Version First Reported In: | 1.7.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
KGeoTag 1.7.0 error message
test image KGeoTag drag and drop error |
||
|
Description
BOF
2025-02-17 08:59:46 UTC
Hi, thanks for your report. I'll investigate this. Created attachment 178465 [details]
KGeoTag 1.7.0 error message
Error message of drag&dropped file.
Program version and system info as provided
I can't reproduce this with git master. I also tried it with v1.7.0. I tried both on my Gentoo desktop at home, which is on Plasma 6.2.5, and here in my office on Artix, which is on Plasma 6.3.0. No difference. Works. I can load files without problems, both by loading them via the menu, and also by dragging and dropping them onto one of the image lists. It's also quite odd that adding the file via the menu works, but not when dropping it, because the drop triggers the very same function that runs when adding an image via the menu … The error message you provided happens when loading the image fails, i.e. the QImage object instantiated with the path is a null image. This is pure Qt, no KDE stuff involved here … Would you be so kind to provide an image triggering the problem, so that I can also try this? Created attachment 178474 [details] test image (In reply to Tobias Leupold from comment #3) > It's also quite odd that adding the file via the menu works, but not when > dropping it, because the drop triggers the very same function that runs when > adding an image via the menu … The error message you provided happens when > loading the image fails, i.e. the QImage object instantiated with the path > is a null image. This is pure Qt, no KDE stuff involved here … > > Would you be so kind to provide an image triggering the problem, so that I > can also try this? This is an image I used as described. It's just a new image created with GIMP, filled with white colour and exported as JPG. I created this test file as I though maybe the camera JPG or the cropped JPG file could may have some data in them that causes the error. As both JPGs caused the error, I tested this blank image to see if this might work, which it doesn't either. Is there maybe a debug build with verbose log file to see when and where it breaks? Is there maybe an AppImage for this program? I have googled for it, but couldn't find one. Thanks! The image does load without a problem if I drop it here, both using git master and v1.7.0 … You can set -DCMAKE_BUILD_TYPE=Debug to make the console output more verbose. I don't think there's some AppImage around. IIRC they create Flatpak and Snap packages for KGeoTag though … Created attachment 178479 [details] KGeoTag drag and drop error As I often see people not being able to replicate my bugs I tend to retest them on 'vanilla' USB-ISO systems. I downloaded the current ISO of KDE neon from https://neon.kde.org/download (User Edition, neon-user-20250202-0745.iso) and downloaded only KGeoTag (1.7) from flathub and OBS to record the desktop. The bug showed up as described: Drag & Drop failed, open though menu worked. As it was also a download option in Discover I tried repo version (user_noble-noble-main; Version: 1.7.0-0zneon+24.04+noble+release+build11). Here KGeoTag didn't even start. Since I had this problem in the past and wasn't able to fix it, I didn't really care as this problem does no longer exist. I also tried to install KGeoTag from snap through Discover (Version 1.5.0-4-geffa7de). Here the drag & drop feature works as expected. (In reply to Tobias Leupold from comment #6) > Thanks! The image does load without a problem if I drop it here, both using > git master and v1.7.0 … > > You can set -DCMAKE_BUILD_TYPE=Debug to make the console output more verbose. > > I don't think there's some AppImage around. IIRC they create Flatpak and > Snap packages for KGeoTag though … I never had to compile anything on Linux as I learned all my dev work under Windows or worked in LUA. So I have to go down the rabbit hole so see where I would set the debug key. Would be neat if there would be an AppImage on the website. AFAIR this can be done automatically. Would be especially nice if there was a debug build. (In reply to BOF from comment #7) > I downloaded the current ISO of KDE neon from https://neon.kde.org/download > (User Edition, neon-user-20250202-0745.iso) and downloaded only KGeoTag > (1.7) from flathub and OBS to record the desktop. That was even on a different laptop and the version of KDE was still 5.2.something If you know how to have an AppImage built automatically, feel free to file a PR adding this! I don't … However, I now dowloaded Neo (neon-user-20250202-0745.iso), installed it into a QEMU VM, booted it, installed all needed dependencies, build KGeoTag git master, downloaded your test image dragged and dropped it onto the unassigned images list. The image was added like it should be. Apparently, this is either some local problem of your machine, or some downstream issue. No matter what I do, I can't reproduce it, no matter where I build KGeoTag (three different distributions tested so far) or if I use git master or v1.7.0. And if I can't reproduce it, I can't fix it … Maybe, this is some Flatpak or whatever issue? May it be some sandboxed KGeoTag isn't allowed to read the file system under some circumstances?! I honestly have no idea how to help you :-( (In reply to Tobias Leupold from comment #9) > If you know how to have an AppImage built automatically, feel free to file a > PR adding this! I don't … > > However, I now dowloaded Neo (neon-user-20250202-0745.iso), installed it > into a QEMU VM, booted it, installed all needed dependencies, build KGeoTag > git master, downloaded your test image dragged and dropped it onto the > unassigned images list. The image was added like it should be. > > Apparently, this is either some local problem of your machine, or some > downstream issue. No matter what I do, I can't reproduce it, no matter where > I build KGeoTag (three different distributions tested so far) or if I use > git master or v1.7.0. And if I can't reproduce it, I can't fix it … > > Maybe, this is some Flatpak or whatever issue? May it be some sandboxed > KGeoTag isn't allowed to read the file system under some circumstances?! I > honestly have no idea how to help you :-( Have you tried the flatpak version as well or just your own builds? As your idea that it might be related to flatpak already was a problem at one time in the for me, I checked this. When I use flatseal to allow KGeoTag access to "filesystem=home" drag & drop works. Though I do not understand why opening the image would work with the regular menu though if it's just about access rights - maybe Wayland and some security thingy could be involved here? Do you think that there could be any difference between X11 and Wayland here? No, I didn't try anything else than a source build, because I can't debug a downstream package. Looks like this is not a bug in KGeoTag's code, but happens by design when using a Flatpak build. I can't say anything about Flatpak though, because I neither create those packages, nor did I ever use Flatpak. Thanks for confirming this to be a downstream issue :-) I think the best solution for you would be to simply use a native package. |