Skip to content

Fix export path when lastExportLocation is empty

When exporting a file for the first time, whether creating it from new or opening a previous document, the location will always default to home directory. I took a look at it and decided on this fix, but I'm unable to test it on other systems and don't know if this is something deeper.

I added these debug lines to the export dialogue:

qDebug() << ">>>>>" << isExporting << d->lastExportLocation << d->lastExportedFormat << QString::fromLatin1(document->mimeType());
qDebug() << ">>>>>" << suggestedURL << group.readEntry("SaveAs", "") << group.readEntry("OpenDocument", "");
qDebug() << ">>>>>" << QFileInfo(suggestedURL.toLocalFile()).completeBaseName() << QStandardPaths::writableLocation(QStandardPaths::PicturesLocation);

The output when I start Krita, open a file, and try to export is this:

>>>>> true "" "" "application/x-krita"
>>>>> QUrl("file:///home/ralek/Google Drive/Art/Art/MawDesign.kra") "/home/ralek/Google Drive/Art/Art" "/home/ralek/Google Drive/Art/Art"
>>>>> "MawDesign" "/home/ralek/Pictures"

So it seems like it knows where it's supposed to be, but the dialogue window doesn't open to it because it seems that the section of code that it supposed to set the default directory for the dialogue:

if (default_mime_type != "all/mime" && !default_mime_type.isEmpty()) {
    QString proposedExtension = KisMimeDatabase::suffixesForMimeType(proposedMimeType).first().remove("*,");
    //This line is responsible for setting filename, which also manipulates filters.
    dialog.setDefaultDir(suggestedURL.isEmpty() ? proposedPath :  QFileInfo(suggestedURL.toLocalFile()).completeBaseName() + "." + proposedExtension, true);
}

Doesn't actually include the 'proposedPath' before the file's basename. This commit adds that and it works properly on my system now.

Test Plan

Try to open a file and export on multiple systems to ensure it's not a local fix.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
  • Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Merge request reports