Created attachment 180817 [details] A Screenshot Of The Erroneous Modal Window STEPS TO REPRODUCE 1. Capture a screenshot or screencast. 2. Delete the file. 3. Select "Open Containing Folder". OBSERVED RESULT > WorkingDirectory= expects an absolute path or '~' EXPECTED RESULT > The file or folder $file_path does not exist. SOFTWARE/OS VERSIONS I am using `spectacle-6.3.4-2.fc42.x86_64` on: > Operating System: Fedora Linux 42 > KDE Plasma Version: 6.3.4 > KDE Frameworks Version: 6.13.0 > Qt Version: 6.9.0 > Kernel Version: 6.14.4-300.fc42.x86_64 (64-bit) > Graphics Platform: Wayland ADDITIONAL INFORMATION This already works if the user merely invokes the file via the hyperlink above the button, hence the exact text in the "Expected" section. I have no idea what version to set in BZ, because the available options utilise a different numbering scheme to what Spectacle itself reports (24.12.3 versus 6.3.4). Consequently, I've set it to "Unspecified".
Created attachment 180818 [details] A Screenshot Of The Expected Modal Window
Created attachment 180822 [details] A Screencast Of The Erroneous Behaviour
Created attachment 180823 [details] A Screencast Of The Correct Behaviour
Version 6.3.4 is in the dropdown, adjusted to that. I can reproduce. I'm not sure of how the hand-offs work between components, but this might be deeper in the stack, like in KIO, as observed in this bug: https://bugs.kde.org/show_bug.cgi?id=492967
Can reproduce, and we should probably fix this, but why are you doing this? If you manually deleted the file, surely you must know that asking the app to show you the folder that the file lives in isn't a valid request anymore, right?
(In reply to Nate Graham from comment #5) Occasionally, I accidentally delete a new screenshot alongside some old ones in Dolphin, then come back to Spectacle's GUI to open the file. It's usually when I'm deleting old screenshots so that I can focus on the new ones, but have accidentally selected the new ones too. Thank gosh for the Wastebin.
I don't know enough to say for certain, but adding a See Also to https://bugs.kde.org/show_bug.cgi?id=498911 as that seems possibly related to an underlying cause?