Another conveniently timed issue, when I make a new pattern, do anything in it, close the window from the menu, (whether saving or not,) & then try making a new pattern, I get a segmentation fault, & the window closes, (& if it’s the only window, seamly2d quits as well.)
Same thing happens in the regular install as well. I don’t think it’s a big deal, but I found it while stress-testing Seamly while I had no internet for a week, & don’t know if it might be more important than I realize. It didn’t interfere with any active work.
I can’t replicate on Windows, Same build date July 30 2020.
Opened Seamly, opened a test file. Changed something.
Clicked File/Exit. it asked me to save, I saved, app closed.
Reopened Seamly, clicked New, got prompt for new pattern piece 1. Clicked OK. Runs fine.
Did the same again, but I didn’t save, app closed. Reopened Seamly, clicked New, got prompt for new pattern piece 1. Clicked Ok. Runs fine.
The intent is to keep working in Seamly on a new pattern, without having unused windows left lying around, not to quit the application. Though I guess the difference, at least on Linux, is just smoke&mirrors.
@Douglas did mention in the other error thread that he was doing away with it. Maybe the dev copy doesn’t have it any more? Here’s the shot:
Okay, I hope I noticed all the details this time
In a new GREY blank waiting-for-a-new-pattern-to-be-made startup screen Seamly window, select “new” pattern
do some work
using, (possibly deprecated) “close pattern” option in the (being deprecated) window menu (see picture above), close the pattern. Possibly I decided I was going in completely the wrong direction, & it would be easier to just start with a blank canvas.
I didn’t bother saving the pattern this time, I did try saving once before & it didn’t make a difference.
now I’m at the WHITE blank waiting-for-a-new-pattern-to-be-made startup screen
I once more click “New”
it asks what to name the new pattern piece
I click “okay”
& the program is gone.
I’ve tried the toolbar, the file menu, & ctrl-n for the new file. All to the same effect. Also inches & cm.
The history is not properly cleaned up upon window->close pattern. Thus even though the pattern was closed, the history entries for this pattern are still alive.
If we now create a new pattern with the same name as before, things get messed up, and we end up with a segfault. If you choose a different name for the new pattern, everything is okay.
The reason is the compare-by-name in the if-clause in QRectF VPattern::ActiveDrawBoundingRect(), which returns true also for the old history items if both pattern names are the same. The segfault is raised in qobject_cast within template <typename T> QRectF VPattern::ToolBoundingRect. This is actually a segfault within the Qt library.
I made a commit fix to the Window-> Close Pattern in a pending New Notch Option pull request. I say pending because it’s hung up on a test at the moment that I need to familiarize myself with.
I want to make some future updates to the menus and the “Close Pattern” menu item would be moved to the File Menu… the function of it remains the same. Stay tuned.
Fixed in a pending pull request.
Too much info for most users here. Can’t do anything about the segfault in the lib - sounds like an issue for Qt. For the purposes of Seamly2D it’s a simple swap of 2 lines in MainWindow->Clear().
Susan… When I click on the Bad Id message - can’t open a second pattern. - as the program closes. Anyhow, It’s all a moot point when the fix in my current New Notch Options PR is able to merge. Which BTW threw me another wrench as I now have to decipher a test on a old (problem?) test pattern piece… or we could just delete that test and the PR test passes.
However, bear in mind that swapping of Qlist items was only introduced in Qt 5.13. To be consistent, one should change the minimum required Qt version to 5.13.
But you are right, this is perhaps not the ideal place to discuss programming related issues. I would like to help and contribute some code, what is the best way to start? I have quite a lot of questions, e.g. regarding code style etc.
I was caught by the keyword swapping, but you swapped lines in order to fix the bug, not items.
(My point was: There has been another merged pull request last month by another dev, which raised the Qt dependency from < 5.9 to 5.13 by swapping of items. But this is a.) not the point of this thread and was b.) implemented by someone else, correct.)
Sort of… the min Qt dependency is the result of choosing to use 5.13.2 on github for the builds, not neccesarily the change Roman made to eliminate that one particular deprecation. Roman used the swapItems() because he could in the automated builds on Github. No doubt he probably saw the deprecated warning while compiling.
It’s a what came first - the chicken or the egg?
I’ll just be happy when the min ver is 5.15… then I won’t see the 250+ deprecation warnings.