feat: new filename extensions

[DSCaskey]

This PR completes the rebranding by replacing the old file extensions with new ones, as well as new icons to go along with them.

Pattern files will now be saved as sm2d for Seamly2d files.

*.val → *.sm2d

Individual measurements will be saved as smis for SeamlyMe Individual Size files.

*.vit → *smis

Multisize measurements will be saved as smms for SeamlyMe Multi Size files.

*.vst → *smms

For comparison here’s the existing icons:

and the new ones:

The “orange” ME icon is for use in SeamlyMe for the “Open Template” actions. It will filter the path for *.vit, *.vst, *.smis, and *.smms.

The Open individual and Open multisize file dialogs will filter for *.vit, *.smis and *.vst, *.smms repectively.

resolves issue #858

[ghost]

👇 Click on the image for a new way to code review

Legend

[slspencer]

I have a question:
why 'SMIN' not 'SMME' ?

[DSCaskey]

We discussed this way back in July in a Zoom meeting. And I posted on the forums after we talked about it . New File Extensions. IN... INdividual measurements MS... MultiSize Measurements ME makes no sense as vit and vst are both used in ME. If there were just individual files, then yes smme would make sense. Also from a "code" perspective it just makes more sense, as all the code refers to individual and multisize... not me and multisize. Conceptually you end up with meMeasurements() along with multisizeMeasurements(). That's the kind of confusing thing RT would do.

…

On Tue, Nov 14, 2023, 3:27 PM slspencer ***@***.***> wrote: I have a question: why 'SMIN' not 'SMME' ? — Reply to this email directly, view it on GitHub <#1041 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHTXADXVILPJSCXRBDMMUCLYEPH2LAVCNFSM6AAAAAA7ILBM76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJRGE4TOMRWGQ> . You are receiving this because you were assigned.Message ID: ***@***.***>

[DSCaskey]

I updated the individual size file icon to the SMIS version.

[DSCaskey]

Just providing a real example of code to help explain why for consistency, smis and smms make more sense than smme and smms:

//Use standard path to individual measurements
const QString dir = qApp->Seamly2DSettings()->getIndividualSizePath();

....

//Use standard path to multisize measurements
QString dir = qApp->Seamly2DSettings()->getMultisizePath();

it's not getMePath()... or worse getMeSizePath().

SMIS and SMMS identify the types the ME files are. SSME does not. Had the app been coded with just 1 measurement file extension, where the xml schema had a measurement type tag in it... that would be a different story. Then ssme would make sense, but it doesn't. Which is another one of those RT mysteries, as there is only one Measurements() class that can have a MeasurementsType::Multisize or MeasurementsType::Individual... so I see no reason for the 2 file types. But... can't change that at this point.