feat: prefill save-as filename and remember folder

[Vladkarok]

Closes #462.

This improves the Save As dialog by using the configured output-filename as the initial filename/path when available. This lets timestamp patterns such as test-%Y-%m-%d.png prefill the file chooser name while still allowing the user to edit it before saving.

It also remembers the last folder selected via Save As and reuses it as the initial folder next time, falling back to the output-filename parent directory when no remembered folder exists.

Verification:

• cargo fmt --all
• cargo test save_as
• cargo check
• cargo clippy --all-targets --all-features -- -D warnings

[RobertMueller2]

Thank you for the PR. This is not a review yet which might take a bit more time.

I'm not sure yet I'm happy with persisting the last used directory beyond the session. Perhaps I'd prefer a save as filename template config/parameter. Although maybe there can be both, as long as the behaviour is intuitive. Please don't do anything just yet, I have to think about this. 😄

If we do go with persisting this, I don't think XDG_CONFIG_HOME is the correct place. IMHO, this is application state rather than config, and thus should be placed in XDG_STATE_HOME. https://specifications.freedesktop.org/basedir/latest/

[RobertMueller2]

I have made up my mind. Let's leave the dir remembering function in.

I'll add a followup issue for an explicit pattern later on, which can be implemented later.

[Vladkarok]

Thanks, agreed on all points.

I just used in my workflow both fixes so combined them in one PR but separating them will be definitely better.

I'll update this PR to:

• reuse the existing output filename resolution path instead of duplicating handle_save logic
• store the remembered Save As directory under XDG_STATE_HOME via the existing xdg crate
• simplify/rename the helper functions so they don't look like test-only wrappers leaking into production

I'll push the fixes to this branch.

[RobertMueller2]

Ok, thanks. I got three final remarks, I think.

• This change introduces two new println! occurrences. We're trying to replace these with eprintln! for better consistency in fix: replace println! with eprintln! #479, but it would be good if other changes wouldn't introduce new ones in the meantime. Can you please use eprintln! in the new sections?
• There's two occurrences of "save_as_last_dir" (outside of test), could this be a CONST?
• When we read the state file, we don't really know what's in there. is_dir() is a decent plausibility check. What if the file contents is very long, e.g. from corruption? In that case I think we could skip read_to_string, e.g. if it's longer than an arbitrary long value of 10000 bytes which should be a reasonable unreachable upper limit for all systems. What do you think?

[RobertMueller2]

I suppose for the last point one might argue that we don't have such checks elsewhere ;)

[Vladkarok]

Ok, thanks. I got three final remarks, I think.

• This change introduces two new println! occurrences. We're trying to replace these with eprintln! for better consistency in fix: replace println! with eprintln! #479, but it would be good if other changes wouldn't introduce new ones in the meantime. Can you please use eprintln! in the new sections?
• There's two occurrences of "save_as_last_dir" (outside of test), could this be a CONST?
• When we read the state file, we don't really know what's in there. is_dir() is a decent plausibility check. What if the file contents is very long, e.g. from corruption? In that case I think we could skip read_to_string, e.g. if it's longer than an arbitrary long value of 10000 bytes which should be a reasonable unreachable upper limit for all systems. What do you think?

Thanks, addressed these in the latest push.

Changes:

• switched the two newly added diagnostics from println! to eprintln!
• introduced constants for the Save As state filename and max state-file size
• added a metadata guard before reading the remembered directory state file, skipping it if it is not a regular file or is larger than 10 000 bytes

[Vladkarok]

I suppose for the last point one might argue that we don't have such checks elsewhere ;)

Agreed, it is defensive, but cheap and reasonable for this tiny state file :)

[RobertMueller2]

lgtm, thanks :)