Show format within filename when exporting file

[gui-marc]

Bug Description

The export_file_window was displaying only the filename instead of the entire path, leading to confusion for users, especially when including dynamic placeholders such as {tag} in the file path.

Cause of the Bug

Within the ExportFileWindow class, the method setOutputFilename split the provided path into m_outputPath and m_outputFilename, causing the window to display only the filename. Consequently, dynamic placeholders like {tag} were omitted from the displayed path, leading to ambiguity for users.

Impact

This behavior caused confusion and made it difficult for users to accurately discern the file's destination, particularly when using dynamic placeholders. It also difficulted clearing dynamic placeholders from the export path, as it is not shown in the window.

Solution

To address this issue, the following changes were implemented:

• Exposed path_formats defined in filename_formatter, modifying its type from vector to array for improved performance.
• During the assignment of m_outputPath and m_outputFilename, dynamic placeholders such as {tag} are now considered part of m_outputFilename and excluded from m_outputPath.

Example

With the new behavior, let's consider the export path: /home/user/{tag}/test/{frame}/file.png.

• m_outputPath will be /home/user/
• m_outputFilename will be {tag}/test/{frame}/file.png

Now, the displayed path will include the entire dynamic placeholder structure, providing users with clear visibility of the file's destination and enabling the editing of these parameters.

Future Considerations

Maintainers should be aware of potential implications when modifying path-related functionalities in the future. Additionally, it's essential to maintain consistency in handling dynamic placeholders across the application to avoid similar issues.

Resolves #4059

I acknowledge that my contributions are licensed under the Individual Contributor License Agreement V4.0 ("CLA"), as stated in CLA.md.

I have signed the CLA following the steps provided here.

[gui-marc]

Hello @dacap, can you review this PR? I think it's a fast PR to review and it would be very useful for me.

Sorry to be so insistent, but this bug was causing me some trouble in a project I'm developing, and it's a little hard for me to compile aseprite in that workspace (I use the steam version there).

[dacap]

Hi @gui-marc, I've just tested with an empty new sprite (that is not associated with a file on disk) and I got:

Anyway checking the code (and the problem to solve) I think we can approach this in a different way. In some way this is related to #4483, so we should find a way to display the output path, or the common path between the original sprite and the exported sprite (and add {path}+path elements to get to the output directory).

What I'm thinking is in something like this:

Where little capsules are the {path}, {tag}, {frame} elements and we should be able to add these easily (writing "{something}" or with some kind of menu/right-click).

Anyway as a first simple version that could be solved with this PR, we could just calculate the common path between the input sprite and the configured output path and remove it + adding all the path elements that goes to the output dir (that might include ../ elements if we are exporting in a parent dir, etc.). This doesn't require any of the changes in the file formatter, just calculating the correct output path/file comparing the selected output full path with the full input path.

[gui-marc]

Hi @gui-marc, I've just tested with an empty new sprite (that is not associated with a file on disk) and I got:

Strange, this seams to be a platform related problem. I couldn't reproduce it on Linux.

But thanks for the suggestion! I'll implement the way you suggested and test the behavior on different environments and then I'll reach out to you again when it's finished.