Sometimes I’m working on a pattern & want to switch measurement files to check my formulas, but the file I want to check it with doesn’t yet have some of the measurements. Now, I can either go back & forth, hoping that I remember which measurements I need, or I can close out my pattern to use the import function in SeamlyMe.
I’d like to either be able to import measurements from a live pattern, or have some manner of exporting measurements to the .vit from Seamly2D
Can I assume you want to import the measurements with it’s value… not just the measurement - which we can do already. Also I assume you just want to import / add a single measurement- not every measurene in a pattern?
I want to import measurements from a .val that is actively being drafted. I have been getting a “Critical Error” stating that “This file is already opened in another window.” & denied access. Which seems like overkill, since I can’t even edit anything in the file, & , albeit with a dire warning, I can open the file a second time in Seamly2D. It would make more sense to be the other way around.
I want to transfer every measurement which the .vit does not yet have.
I don’t care so much about the measurement being pre-filled, especially since at the moment I’ve been switching between doll & human measurements, but don’t see it as a problem either.
That’s the file locking mechanism… which means you can’t open the file again until the lock is released. It’s another one of the things I had to unravel in regards to updating the Autosave feature - which BTW I had to put on hold till I can figure out how to sync the preference settings file between multiple instances of the app running.
I know SeamlyME will import measurements from a .val file - as I’ve done so to get a pattern a user has posted without the .vit file - but I’m not sure what happens if you already have a .vit open? Is import disabled? Or dies it just overwrite everything? Which maybe this is why you suggested a measurement merge feature awhile back? Seems at minimum we could alter the current import routine to add only the measurements from a source .vit that don’t exist in a destination .vit. idealy though my suggestion in the other topic to merge 2 souces into a new 3rd destination is a more elegant solution, as it leaves the source files intact.
A rather shoddy lock, I say! Since it only locks out 'Me, which only wants to look at it & loosely latches '2D, which could very well damage it.
As far as I can tell it is additive, it pulls in only the unique measurements, in their default empty state, from .val’s
Merging sources is a tangential question, & I think ought to be able to include the filled out formulas in the target file.
There has to be a lock though… you can’t have 2 copies of the same file open or you won’t know what state the file is in. I know you can view (like in Notepad) an open pattern - I do it all the time - I would think though you can’t save to the file while Seamly2D has a lock on it.
Yes, but the lock only applies to the one program that can’t make changes. It does not stop one from opening the same file multiple times in Seamly2D. I can open the same file in multiple instances of Seamly2D, (with a warning.)
Point taken. I’d have to look at the code again, I’m not sure what type of Q lock is used - read, write, or both. I believe even though you can open a locked pattern. file, you won’t be able to “Save”, but you can “Save as”.
I played last evening with the app in regards to the file locking, and you’re correct… it’s rather shoddy. It really doesn’t protect a pattern file at all - whether you’re opening multiple copies within Seamly2D or opening / saving from an external editor.
Based on the way I’m familiar with the way some apps I use it should do one of several things 1) Literally lock the file so only the app that has the lock can read / write the file. 2) If you want to be able to open multiple copies in Seamly2D it should present a message box stating its being used, do you want to open it as “unamed” (or some other name). 3) If you want external editors access to the file, then Seamly2D has to know about when changes have been made so the user has the option to update the ooen file in Seamly2D - much like Qt Creator does if you use an external editor (like I do using Atom), where if a file is open in Creator, and you save changes it in Atom, when you go back to Creator it asks do you want to save the file in Creator.
1& 2 are pretty straight forward. 3 a bit more work… rather like syncing with a measurement file when you make changes to a vit in ME.
Ran into this again. Not sure I managed to clearly communicate the problem last time because SQUIRREL!!!
While Seamly2D has an .sm2d file open SeamlyMe is unable to read the file in order to import measurements from it, such as for making a measurements template for that particular pattern.
Assuming that we’re still considering combining '2D & 'Me, which the AppImage is practically a proof of concept of, an option to Export Measurements to a new .smis would at least make it easy to find the measurements used by the current pattern.
But, circling back around, I assume that removing 'Me’s inability to parse a locked .sm2d to extract the measurements used would be the easiest, & would open up the most possibility for the foreseeable future.
Got it… because the 2D pattern file is locked so ME can’t open it.
Which begs the question - how to allow Me to read locked in use 2D files? 
If the apps were merged it would not be an issue as the “app” would obviously have access to the 2D file. Merging the 2 apps would also simplify the whole build process from the project files to the CI. I think the ME side would benefit as it’s kinda of an orphan with much of the work spent on 2D.
What about removing the dialog? I tried commenting out lines 1655-1660 in ./Seamly2D-2025.12.1.213/src/app/seamlyme/tmainwindow.cpp & it appears to work. I assume it could cause trouble if I was actively editing in '2D at the same time I’m extracting measurements in 'Me, but that seems like an unlikely scenario. Is there something I’m missing?
A more robust and graceful solution would be:
if (!lock.IsLocked()) { answer = QMessageBox::warning(this, tr("Locking file"), tr("This file already opened in another window. Ignore if you want " "to continue (not recommended, can cause a data corruption)."), QMessageBox::Abort|QMessageBox::Ignore, QMessageBox::Abort); if (answer == QMessageBox::Abort) { return; } }
Fixed.
Now if you attempt to import measurments from a pattern that is already open you are presented with the same Dialog as when you try to open a pattern that is already open:
Note: I used the same message text as it saves from translating a new message. I can just cut & paste from the 2d.ts to the me.ts files.
Ignoring will open the pattern file anyways and import the measurements. Aborting will cancel the import allowing user to close the pattern file, and try again.
That being said as @Pneumarian has alluded to, there is little to no chance of any data issues. Me is only opening the pattern file to read, and never writes which is where the 2 pattern files can get out of sync.
How long does it generally take a PR to make it to the Releases page?
All PR’s require another reviewer to approve it, so it depends on how quickly it gets reviewed, and whether the reviewer merges the PR or leaves it for the author of the PR to merge it. Once s PR is merged to develop a pre-release is available, and of course on sun-mon (depends on one’s time zone) the CI is run and the weekly releases are built.
That being said… I haven’t made a PR for this yet, but expect to over the next day. I just need to do an lupdate, and push the branch. So theoretically it should make next week’s release. If not I will bring it up during next tues meeting, and Susan would likely merge it then… creating a pre-release.
Update: A PR is now open for review. 
Which also means for anyone with a Github account the Actions artifacts are available:
In this case… about 7 hours. @csett86 just reviewed and merged it. Should show up as a pre-release as soon as the merge build finishes, and of course in the next weekly build. 
