Repository navigation
Conversation
This was referenced Oct 12, 2026
zuujiscom
added a commit
to zuujiscom/photocraft
that referenced
this pull request
Oct 15, 2026
…28, #4394) The GTK file chooser behind the desktop portal keeps the typed name when another file type is picked, and rfd 0.17.2 reads only the file name from the portal's answer, so Untitled-1.psd with PNG picked was written as a PSD. On Linux, Save As now asks the portal's FileChooser.SaveFile itself (over the zbus already used for the portal), reads current_filter, and gives the name that type's extension: an extension PhotoCraft saves is replaced, none or another is appended. If that names an existing file, the dialog opens again under the new name so the portal asks before replacing it. rfd remains the fallback without a portal, and this can go once an rfd release reads current_filter (PolyMeilex/rfd#341). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
zuujiscom
added a commit
to zuujiscom/photocraft
that referenced
this pull request
Oct 15, 2026
… request handle Review follow-ups, checked on real GNOME 46 and KDE Plasma 6.7.5 sessions (Wayland and X11): - An extension the user typed is kept, as in PolyMeilex/rfd#341: only a name with none, or still with the extension the dialog opened with, takes the picked type's. GTK reports the type even when it is untouched, so art.png with the PSD type left alone was saved as art.psd. - The dialog opens on the stem (test), as on Windows (#4407): with test.psd in the name and PNG picked, GTK asked to replace test.psd, which the save leaves alone. A name that then exists is asked about again under that name; the rule compares against the suggested name, so a test.psd GTK completes back still becomes test.png. - Response 2 (GNOME's dialog closed with Esc) is a cancel: it fell back to rfd, which opened a second Save As. - The answer is awaited on the handle SaveFile returns, which a portal older than 0.9 picks itself (the Request documentation). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner
|
Sounds like a portal issue. Lack of overwrite confirm dialog aside, a workaround in RFD would break for Flatpaks and Snaps which can't write to arbitrary paths. |
skylartaylor
added a commit
to storytold/photocraft
that referenced
this pull request
Oct 16, 2026
…, #4394) (#6151) * Save As on Linux: the file type picked sets the extension (#6121, #4328, #4394) The GTK file chooser behind the desktop portal keeps the typed name when another file type is picked, and rfd 0.17.2 reads only the file name from the portal's answer, so Untitled-1.psd with PNG picked was written as a PSD. On Linux, Save As now asks the portal's FileChooser.SaveFile itself (over the zbus already used for the portal), reads current_filter, and gives the name that type's extension: an extension PhotoCraft saves is replaced, none or another is appended. If that names an existing file, the dialog opens again under the new name so the portal asks before replacing it. rfd remains the fallback without a portal, and this can go once an rfd release reads current_filter (PolyMeilex/rfd#341). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Save As on Linux: keep typed extensions, open on the stem, follow the request handle Review follow-ups, checked on real GNOME 46 and KDE Plasma 6.7.5 sessions (Wayland and X11): - An extension the user typed is kept, as in PolyMeilex/rfd#341: only a name with none, or still with the extension the dialog opened with, takes the picked type's. GTK reports the type even when it is untouched, so art.png with the PSD type left alone was saved as art.psd. - The dialog opens on the stem (test), as on Windows (#4407): with test.psd in the name and PNG picked, GTK asked to replace test.psd, which the save leaves alone. A name that then exists is asked about again under that name; the rule compares against the suggested name, so a test.psd GTK completes back still becomes test.png. - Response 2 (GNOME's dialog closed with Esc) is a cancel: it fell back to rfd, which opened a second Save As. - The answer is awaited on the handle SaveFile returns, which a portal older than 0.9 picks itself (the Request documentation). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * style(automation): format smart filter refresh closure --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: skylar taylor-barrick <hi@skylar.cc>
Author
|
Good point, I hadn't thought about the sandbox: a Flatpak or Snap only gets write access to the path the portal hands back, so renaming it in rfd would point at a file it can't write, and it would skip the portal's overwrite check too. I'll take it to xdg-desktop-portal-gtk instead. Happy to close this one. |
This file contains hidden or 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
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.
Summary
With the XDG portal on GTK (
xdg-desktop-portal-gtk), choosing a different filter in a savedialog doesn't change the file name. The
Responsecarries the selected filter incurrent_filter, but rfd only readuris, so the app got the old extension back:An app that suggests
Untitled-1.psdand offers PNG, JPEG, ... getsUntitled-1.psdwhen theuser picks PNG, and writes a PSD. The macOS save panel follows the selected format (#328), and
on Windows
SetDefaultExtensionmakes the dialog swap the extension, so only Linux behaved this way.This PR reads
current_filter's label from the response, finds the filter rfd sent with thatlabel, and applies its first extension to the returned path when:
set_file_name, and that extension isn't oneof the selected filter's.
A typed extension is kept (
Untitled-1.pngtyped with the PSD filter selected stays.png), asis any extension that already matches the filter (
psd/psb, any case). Filters whose firstextension is
*or empty change nothing. If the renamed path already exists, the path theportal returned is kept, since the portal only confirmed overwriting that one.
Only
save_fileuses the new field;Response::Selectedgets a second element that the openand folder paths ignore. The zenity fallback is unchanged.
Testing
with_chosen_extension): suggested extension replaced,typed extension kept, matching extensions kept (case-insensitive), missing extension added,
*/empty filters ignored.cargo test --no-default-features --features xdg-portal,cargo clippy --all-targets(default and xdg-portal),
cargo fmt.xdg-desktop-portal-gtk: a save dialog opened withUntitled-1.psdand PSD, PNG, ... filters.Untitled-1.psd, afterUntitled-1.png.Untitled-1.pngtyped:Untitled-1.pngbefore and after.Found through PhotoCraft (storytold/photocraft#4328), where Save As › PNG on Linux wrote a PSD.