2021.01 - Export filename not remembered

[MichaelAtOz]

In 2019.05, when exporting it remembers the filename used and presents it again on the next export.

e.g.
Open file Some fantastic design.scad
File/Export, the pre-filled filename is Some fantastic design.stl,
edit that to Some fantastic design-with-2021-01-a.stl, save.

File/Export, the pre-filled filename is Some fantastic design-with-2021-01-a.stl,
so it is easy to change 'a' to 'b', save.

In 2021.01, it doesn't remember and just offers Some fantastic design.stl.

The only mention in the release is 'Fix export format name handling',
a search here found #3029, that didn't get much review at the time.

I believe the original behaviour is better.
Other's may differ?? Perhaps as an option?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[rcolyer]

I was about to agree with you because this sounds like a regression as you describe it. But I think the issue being resolved there was involving multi-tab editing, where the last export ends up pretty inappropriate as a starting point if you switch tabs. So it's not as simple as reverting that change. To restore the old behavior without adding weirdness for tabbed editing, I think it would need to track last export in some manner that can stay associated with the tabbed windows.

[nophead]

This is annoying as I added the original code to remember it and I don't use tabs as most things don't make sense with them.

[t-paul]

I don't see any problem tracking that per tab, that seems to be the most useful way to do it anyway.

[TheAndr0id]

I'm glad to see this is flagged as a bug and added to the the possible Bugfix Release.

From looking at the above mentioned change (#3029) it looks (to me) that the culprit here is the call to activeEditor->filepath (lines 2972-2975). I pulled that entire part out and put back the code from the 2019-05 release (path = path_it->second;) and it seems (so far) to work as it did. This isn't a total fix, just a hack so I don't have to revert to the 2019-05 release. The final code looks like this:

QString MainWindow::exportPath(const char *suffix) {
  QString path;
  auto path_it = this->export_paths.find(suffix);
  if(path_it != export_paths.end())
  {
     path = path_it->second;
//    path = QFileInfo(path_it->second).absolutePath() + QString("/");
//    if(activeEditor->filepath.isEmpty())
//      path += QString(_("Untitled")) + suffix;
//    else
//      path += QFileInfo(activeEditor->filepath).completeBaseName() + suffix;
  }
  else
  {
    if(activeEditor->filepath.isEmpty())
      path = QString(PlatformUtils::userDocumentsPath().c_str()) + QString("/") + QString(_("Untitled")) + suffix;
    else {
      auto info = QFileInfo(activeEditor->filepath);
      path = info.absolutePath() + QString("/") + info.completeBaseName() + suffix;
    }
  }
  return path;
}

[otsakir]

I've done research in the algorithm that suggests export paths and filenames and also played with the behavior of the application. To make sure i'm in the right page i'll first take down the existing algorithm and then suggest another one (built on top of it) that hopefully covers better the requirements.

Existing algorithm

When exporting an .scad file to a suffix (.stl, .obj etc.):

For the path

• If there has been any .scad file exported with the same suffix use its destination path.
• Otherwise use the path of the .scad file as a destination path.
• If this is a new file (can't guess the path from the .scad file), further fallback to PlatformUtils::userDocumentsPath() as a destination path.

For the basename

• Use the "base name" of the .scad file adding the suffix at the end as a filename.
• When this is a new file (i.e. there is no base name) use "Untitled" as a base name.

At the end

• Keep the determined exported path for the specific suffix for future use.

State

MainWindow::export_paths holds mappings of suffix -> "last exported path". Only a single mapping for each suffix exists. This seems to be our lack of flexibility.

Proposed algorithm

Introduce a seperate suffix->path map data structure for each tab open in the editor (EditorInterface class). Each .scad file will have its own "last exported path" for each suffix. Fallback to previous algorithm if the mapping is not there. At the end store the suffix->path mapping entry both in the EditorInterface object and the MainWindow::export_paths

So, again, when a exporting an .scad file to a suffix (.stl, .obj etc).

• Check in MainWindow::activeEditor if there is already a registered path for the .stl suffix. So, if previously the "/xx/xx/Some fantastic design-with-2021-01-a.stl" file was used it will be easy to change it to "/xx/xx/Some fantastic design-with-2021-01-BBBB.stl".
• If there is no suggested path in MainWindow::activeEditor, fallback to the previous mechanism:
  • Try to use the path where the last .stl file was exported to from MainWindow::export_paths. Use the basename from .scad file.
  • If there is nothing in MainWindow::export_paths, take the path from the .scad file.
  • If there is no .scad file saved yet (we have a new file) fallback to PlatformUtils::userDocumentsPath()

Thoughts ?

[jordanbrown0]

I only rarely use multiple tabs for multiple projects, and so hadn't noticed that the current behavior surprises me: I expected that when I export a .stl (or whatever), it would default to the same directory that the .scad file is in. But no, as you describe above, it defaults to the last place that I saved a .stl, even if it was for a different project in a different tab.

Your proposal would improve that; at least if I'd exported from a particular tab it would go where I expected when I came back to that tab. However, I don't think that falling back to a central "sticky" registry is right. I think that what I do for exports in one tab should not affect what I do in another tab. That is, if I open dirA/a.scad in one tab, when I export an STL file it should default to dirA, and then when I open dirB/b.scad in another tab and export an STL from there, it should default to dirB. A central registry would have it default to dirA.

So I would suggest a modification, dropping out the central registry.

• If there's a previous export for that suffix from this tab, default to that path (as you suggest).
• If the tab has a path for its .scad file, default to that.
• Default to the platform-specific documents directory.

There may reasonably be people who want to have all of their .stl files collect in one place, who would be annoyed that they need to re-select that place for each tab. (But note that they currently have to reselect that place for each session.) For those people, add a preference controlling the default location for each file type, with the default being "unset". That would make the sequence be:

• If there's a previous export for that suffix from this tab, default to that path (as you suggest).
• If there's a preferred location set for this suffix, default to that.
• If the tab has a path for its .scad file, default to that.
• Default to the platform-specific documents directory.

People like me who put the .stl next to the .scad would just use the default-default, which devolves to the same directory as the .scad, or the documents directory if the tab doesn't have a file yet.

People who want to collect their .stl files in one place would set that preference (which would stick from session to session, a win for them), and would get that.

People who want to do something special for this project would have to select the alternate location once per session, but thereafter it would be sticky for that tab.

The basename remains as you say: same as the .scad file, else Untitled. (Note that there are other proposals to have a way for the program to recommend a base name; they wouldn't conflict here but need to be kept in mind.)

[otsakir]

Sounds good.

The basename remains as you say: same as the .scad file, else Untitled.

Clarifying basename:

1. User opens /dirA/a.scad.
2. Exports to .stl. Dialog suggests /dirA/a.stl.
3. Changes to /dirA/dirB/a-XXX.stl and does save.
4. Exports again to .stl.
5. Dialog suggests /dirA/dirB/a.stl. Not /dirA/dirB/a-XXX.stl.

Does this look ok ?

[jordanbrown0]

I suspect that the path and the base name discussions can be kept independent, and that's probably best.

I don't have a strong feeling on the question you ask - but the key thing is that you're not proposing to change it, right?

[TheAndr0id]

Sounds good.

The basename remains as you say: same as the .scad file, else Untitled.

Clarifying basename:

1. User opens `/dirA/a.scad`.

2. Exports to .stl. Dialog suggests `/dirA/a.stl`.

3. Changes to `/dirA/dirB/a-XXX.stl` and does save.

4. Exports again to .stl.

5. Dialog suggests `/dirA/dirB/a.stl`. Not  `/dirA/dirB/a-XXX.stl`.

Does this look ok ?

Sorry, it's been so long since I commented on this issue, so I'm going to be a little behind on this.

First I don't use multiple tabs. If I'm working on multiple projects I use separate instances of OpenSCAD.

The description above is actually describing the issue, not the solution. If I change the file name to /dirA/dirB/a-XXX.stl then expect the dialog should continue to offer the latest value I've entered ( /dirA/dirB/a-XXX.stl). If I haven't exported yet, it should offer the default of /dirA/a.stl.

Check how the 2019-05 release handles this - that's the expected behaviour.

The reason this is important is for parameterized scad files. I have a scad that creates custom funnels and nozzles. If I'm using it to create a funnel, I want to keep calling the STL funnel-something.stl. Not FunnelNozzleMaker.stl. If I tweak a setting in the customizer it's annoying as hell to keep having to change the name of the exported file back form FunnelNozzleMaker.stl to Funnel-something.stl. If I'm creating multiple sized objects using the parameter settings then I'm going to want the export window to show what my last export filename was. This is what 2019-05 did and it worked perfectly.

Your changes would not address this. The name associated with the STL export should be attached to the structure keeping track of the file tab. You have to keep details for the current tab tracked somewhere for saving/reading/updating/parameters/code trace/etc. so just attach the STL export file name to that same tab tracking structure and use the same algorithm that you used in the 2019-05 release just with that new variable from within the tab tracking structure. The only change here should be just the name of the variable itself from a single "global" value to one connected to the active tab.

There's not an issue with the 2019-05 algorithm, the issue how the new multi-tab system was implemented in it.

[jordanbrown0]

I don't have a strong feeling about whether the export file name should be sticky (as you request).

But it does seem like the path and basename questions can be addressed independently, especially since there are proposals floating around for having the OpenSCAD program suggest the basename.

[otsakir]

I agree. We can address the proposed path and basename aspects independently. Path comes first. Modify existing mechanism so that it suggests a sensible export path in a per-tab fashion.

Having this in place will also provide some flexibility to reusing last export filename. It will be in the proposed directory and user will just have to click on the previously exported filename to re-use it. That's just a one click away trip.

As a second iteration on the issue we can tweak the proposed basename behavior which will be easy. Even in the existing algorithm the full path including the last used filename is kept internally. In the end, this is an "Export filename not remembered" issue.

So, moving forward i plan to implement the per-tab algorithm as suggested by @jordanbrown0 above:

• If there's a previous export for that suffix from this tab, default to that path (as you suggest).
• If there's a preferred location set for this suffix, default to that.
• If the tab has a path for its .scad file, default to that.
• Default to the platform-specific documents directory.

For the preferences, i was thinking to utilize this preference group:

I'm just wondering whether it makes sense (a) to just add a single export directory override (for all suffixes) or (b) have a list of them i.e. a different textbox for each suffix. I think (a) is better. Adds a degree of flexibility but is easier to implement and easier to maintain.

[jordanbrown0]

The "Advanced" tab is getting overfull; it might be appropriate to add a new "Export" tab. But that can be done at any time.

[otsakir]

The implementation is through. Regarding the new "Default Export Directory" preference, I used the "single" textbox option and added it under the Advanced/Export Features section.

It currently looks like this: