refactor: rename SnapOrca references to Orca in CAD components to avoid confusion and update recipe versioning

This commit is contained in:
SoftFever
2026-08-27 18:49:50 +08:00
parent 0aeb6df122
commit 5a170520d3
13 changed files with 36 additions and 36 deletions
+2 -2
View File
@@ -183,7 +183,7 @@ SCENARIO("CAD recipe blob survives a 3mf save/load cycle", "[3mf]") {
// The GUI saves/loads projects via the BBS-native 3mf backend (store_bbs_3mf /
// load_bbs_3mf), NOT the PrusaSlicer 3mf.cpp. This locks in that store_bbs_3mf embeds the
// CAD recipe (Metadata/SnapOrca_cad.bin) byte-for-byte, read back the same iterate-and-match
// CAD recipe (Metadata/orca_cad.bin) byte-for-byte, read back the same iterate-and-match
// way load_bbs_3mf does. The full GUI reopen is verified live on the Design tab.
SCENARIO("CAD recipe is embedded in the BBS 3mf archive", "[3mf]") {
GIVEN("a model carrying a binary cad_recipe") {
@@ -229,7 +229,7 @@ SCENARIO("CAD recipe is embedded in the BBS 3mf archive", "[3mf]") {
if (!mz_zip_reader_file_stat(&zip, i, &st)) continue;
std::string name(st.m_filename);
std::replace(name.begin(), name.end(), '\\', '/');
if (boost::algorithm::iequals(name, std::string("Metadata/SnapOrca_cad.bin"))) {
if (boost::algorithm::iequals(name, std::string("Metadata/orca_cad.bin"))) {
got.resize(st.m_uncomp_size);
mz_zip_reader_extract_to_mem(&zip, i, got.data(), got.size(), 0);
break;
+1 -1
View File
@@ -3987,7 +3987,7 @@ TEST_CASE("golden recipe v1 still deserialises", "[CadDocument]")
cereal::BinaryInputArchive ar(iss);
uint32_t v;
ar(v);
REQUIRE(v <= CadDocument::SNAPORCA_CAD_RECIPE_VERSION);
REQUIRE(v <= CadDocument::ORCA_CAD_RECIPE_VERSION);
ar(features);
}