Open a project from a URL as a project, and fix the drop dialog default

[KuzuriAo]

Two related but independent problems that show up when opening a model from Snapmaker Space while a project is already on the plate. Fixing either one alone leaves the other.

Platform scope. Problem 1 is macOS specific in practice, because macOS delivers the URL to the already running instance through MacOpenURL, so the model lands on an occupied plate. On Windows the click starts a new instance with an empty plate, so the escalation never triggers. Linux untested.

Problem 2 is not platform specific. It affects anyone dragging a .3mf onto an occupied plate, on any OS.

1. The "Drop project file" dialog should not appear at all

Clicking "Open in Snapmaker Orca" on a Space page already tells the app which project to open. But the download is handed to Plater::load_files(const wxArrayString&), which is the drag-and-drop entry point (its own comment says so), and open_3mf_file() escalates to the prompt whenever the plate is not empty:

bool not_empty_plate = !model().objects.empty();
bool load_setting_ask_when_relevant = ... == OPTION_PROJECT_LOAD_BEHAVIOUR_ASK_WHEN_RELEVANT;
LoadType load_type = determine_load_type(filename,
    (not_empty_plate && load_setting_ask_when_relevant) ? OPTION_PROJECT_LOAD_BEHAVIOUR_ALWAYS_ASK : "");

So a cold launch opens the project without asking, and a warm one interrogates the user, for exactly the same action.

The download path now passes from_url, which suppresses that escalation and nothing else:

• The global Load Behaviour preference is still honored. A user who set "Always Ask" or "Load Geometry Only" still gets what they asked for.
• load_project() still calls close_with_confirm(), so unsaved changes to the current project are still protected. That is the prompt that belongs here, and it already existed.

2. The dialog defaulted to the destructive option

When the dialog does legitimately appear, it preselected "Import geometry only". It records the user's choice in import_project_action on OK, but never read it back, because m_action was hardcoded to 2 (LoadGeometry).

It now initializes from the stored choice, falling back to OpenProject rather than LoadGeometry.

That fallback matters. LoadGeometry sets load_config = 0, so the embedded printer, filament and process settings are dropped. On a multi-color model the practical result is that the paintwork is re-rendered in whatever filaments the previously loaded project happened to use, so the creator's color work is visibly lost rather than merely mis-referenced. The plate still renders and the model still slices, which is what makes it dangerous: nothing reports an error.

It is a poor default for a dialog titled "Drop project file", and a particularly poor one for the option a user is most likely to accept without reading. That leads to something like this:

If the user correctly changed it to Open as project, it would load properly:

Testing

Built and run on macOS 26.6.2, Apple Silicon, Release build. Load Behaviour left at its default, "Ask When Relevant".

Confirmed:

• Cold launch from a Space link: unchanged, opens the project.
• Snapmaker Orca already open with a model on the plate, then "Open in Snapmaker Orca" on a second Space model: opens as a project, no dialog.
• Same, after making an unsaved change to the first model: still prompted to save changes first.
• Drag and drop a .3mf from Finder onto an occupied plate: dialog still appears, as it should, and now comes up with "Open as project" selected rather than "Import geometry only".

Not exercised: Load Behaviour explicitly set to "Always Ask" or "Load Geometry Only". Those paths are untouched by this change (from_url only suppresses the escalation to ALWAYS_ASK, it does not override the stored setting), but I have not run them.

Reproduction models for the original problem, both public on Snapmaker Space:

• https://space.snapmaker.com/en/model/5942-baby-dragon-rudolph-3mf-included-no-supports
• https://space.snapmaker.com/en/model/358-snap-carousel-by-riciery-techtronic3d

Note

This code is inherited from upstream OrcaSlicer and the same two problems exist there. I am happy to send it upstream as well, but the impact is sharpest here, since Snapmaker Space exists specifically to distribute tuned profiles and this is the path that discards them.