Cura: Could we pretty please go back to using native file dialogs on Mac...

[filipgoc]

Application Version

3.3.1

Platform

Mac, High Sierra

Additional Information

This clearly betrays my ignorance: I cannot see why the native file dialog was replaced with a custom one.

Are there some threads discussing this? I could not find anything.

From my ignorant user perspective, it's unexpected, strange, linux looking, and does not support my usual workflows (be it shared favorite places, be it drag and dropping files within file dialogs, be it combining spotlight or alfred with the file dialog... everything is broken 😢).

I am trying not to be just criticizing... I am just curious what are the benefits of this new thing since I cannot see but the problems.

[ChrisTerBeke]

I'm not aware of any file dialog changes....

[ChrisTerBeke]

Current master branch on my Mac:

[filipgoc]

Ha! Fascinating. In that case... puzzlement has arrived.

This is my file dialog (for example File > Open) In Cura 3.2.1
edit: in fact, this only pertains to file saving

And this is my file dialog in Cura 3.3.1

Whoa!

[ChrisTerBeke]

3.3.1 shows the same native dialog for me as master branch from source.

[filipgoc]

Thanks for the screenshot @ChrisTerBeke . Once I have something replicable/ understandable, I'll post more.

[filipgoc]

I just downloaded and installed it from Ultimaker's website (I am not able to compile my own Cura yet.)

[fieldOfView]

I'm not aware of any file dialog changes....

Then you should pay more attention ;-)
https://github.com/Ultimaker/Uranium/blob/master/plugins/LocalFileOutputDevice/NonNativeFileDialog.py
This class tries to fix double file extensions problems on Mac OS X with the FileDialog, eg .curaproject.3mf or .gcode.gz

[ChrisTerBeke]

Then why am I not seeing it in both the 3.3.1 build nor master?

[fieldOfView]

Because you are not saving a gcode file to a local file?

[filipgoc]

I'm confused. So is there or is not there a new file dialog in Cura? If there IS a new dialog, then my original question stands :-) !

[fieldOfView]

There is a new dialog, but only for saving files. Opening files should have the proper dialog still.

The non-native dialog for saving files is a workaround for a bug where double extensions such as .gcode.gz or .curaproject.3mf don’t work on OSX with the standard dialog (a Qt issue, if I am not mistaken).

[ChrisTerBeke]

It seems that that is the case indeed. So the new dialog fixes some issues while introducing others.

@diegopradogesto CC

[filipgoc]

You're right @fieldOfView , the open dialog is fine. It's just the saving dialog.

I have to say that I was just fine with .3mf being the extension on Mac, no issues there, but I understand that cross platform unification is worth something. Congrats on figuring that one out! This has been around for a while.

---

That being said... there are many things (viz original post) about this dialog and that makes it a major pain to work with.

In attempt to make this actionable, here's the

#wishlist to fix #brokenthings in the new save dialog:

• make standard mac shortcuts for navigating files and folders work (yeah!)
  
  
  
  • cmd + arrow up | cmd + arrow down
  
  
• make drag and dropping files and folders into the dialog behave like native (as in navigate to that path)
• display Favorites (favorite place) like native (same as in finder, path finder, and others... most alternative file manages manage to share this so there must be some shared list of favorite locations)
• make goto path command function (cmd + shift + G) like native (this one is personally low priority, but it was still surprising this seemingly system wide backup way to make the dialog behave failed)

[diegopradogesto]

The save file dialog has changed in mac a couple of weeks ago, just before the 3.3 release. We noticed that saving the .gcode.gz (or any double extension file) in Cura, the native file dialog automatically attached 3 times the double extension (e.g. myfile.gcode.gz.gcode.gz.gcode.gz). Jira ticket for reference was CURA-5228.
We had different opinions in the team, but the decision was to implement it "manually", not using the native file dialog, since this is a known bug in Qt (not fixed): https://bugreports.qt.io/browse/QTBUG-44227
I will tag this thread as discussion and improvement and so people can express their opinions about this topic.

[filipgoc]

#wishlist to fix #brokenthings vol II:

• fix the bug that fails to save any file extension if not explicit in the dialog
  
  
  
  • already reported https://github.com/Ultimaker/Cura/issues/3735
  
  
  • self-evident and not news, but I wanted to have this all in one place
  
  

[Chompworks]

Just came across this after upgrading from 3.2.1 to 3.3.1.

Really don't like it. The workflow is a lot worse for navigating through computer to Volumes to SD card now on OS X.
Not sure how a new user would react if they don't know how OS X arranges USB/SD devices.

As a suggestion: Is it possible to add a checkbox in the preferences to choose between native and replacement file dialogues? Then users can choose which they use.
For me, I'm not saving any double extension files for example, so this is just inflicting pain and extra process for no benefit for the printers I use Cura with (UM2+, CR-10, Kossel).

[Chompworks]

...also, hit a bug in it too after switching from my UM2+ profile to my CR-10 profile and then saving a separate file:

It appears sometimes /Volumes won't show:

So you have to then right click and show hidden files to get it to display.

I'm sure you can appreciate why this isn't ideal behaviour.

[Chompworks]

Another issue with the non-native file dialogue: if a lock tab is in the locked position on the SD card, the dialogue just exits when you attempt to save to the SD card. No error message, or warning that the volume is read only.

[Chompworks]

Another issue - if you name a file e.g. "thing to print" and delete the ".gcode" at the end of the file name field - the new file dialogue won't append the .gcode to the file name.

Expected behaviour is that it would output a file called "thing to print.gcode"
Actual behaviour is that you get a file called "thing to print", missing any file extension.

[franklinharper]

Before reading this thread I was unable to use the non-native dialog to save files to my external storage device. I had to resort to a 2 step process:
1) save file to internal storage
2) use Finder to copy the file to the external storage device

This is a waste time. Of course now I know how to save directly.

When using the native dialog this wasn't a problem because the external storage device is clearly displayed in the dialog.

[MacLemon]

I added a few more reasons why using any non-standard file-select dialog on macOS is a bad solution in #3917. Also, you won't be able to implement all the functionality of the native file-select dialog in a third party one. It's just a waste of time, just switch back to the native one and everyone will be happy again. :-)

[Chompworks]

looks like they're changing things again for the next Cura release given the response to this bug:
https://github.com/Ultimaker/Cura/issues/3735

[diegopradogesto]

We had some internal discussions about what to do with this and we decided to revert and go back to the native dialog, since we think it's the lesser of two devils. Those are the main drawbacks of each solution:

Known bugs in the native file dialogue:

• The file extension is doubled or tripled on MacOS if the extension has a period in it (like .gcode.gz).
• When saving such a double extension, the user always gets a warning that the actual file extension .gz is not the same as the desired file extension .gcode.gz, even though the file name ends in .gcode.gz.

Known bugs in the custom file dialogue:

• It looks ugly.
• You can't save to a different drive than what the Working Directory is on. So no saving to a hard disk if you're running Cura from an SD drive, and no saving to a USB stick.
• It includes quite a lot of code which is hard to maintain.

For Cura developers, this is the reference to the ticket: CURA-5476

[Ghostkeeper]

This is implemented in the next release. We've reverted to the native file dialogue and are just taking the hit that some of your files will have more than one extension. Hopefully Qt will solve this in a future update.

[filipgoc]

It's as important to realize when it's necessary to go a step back as it is to be pushing forward.
It as a good attempt; it just wasn't meant to be.