BUG: Internal Paths are "orphaned" when it's pattern piece is deleted

[slspencer]

• Describe the bug
  When a pattern piece is deleted, the internal paths aren't deleted.

• How To Reproduce the bug:

  In Draft mode:
  - Create a pattern piece.
  - Add a dart then "true" the darts with the True Darts tool.
  - Create a pattern piece detail.
  - Add an internal path for the dart to the detail.
  Go to Detail mode:
  - Delete the detail.
  Return to Draft mode:
  - Try to delete any item in the Dart. It should be able to be deleted but it's referenced in an unused "orphaned" Internal Path object.
  - Orphaned Internal Paths can only be deleted by opening the XML file in an editor and deleting it manually.

• What should have happened
  When deleting a pattern piece, check it's Internal Paths for number of occurrences in the file and delete the Internal Paths that occur only once.

• Screenshots

• What's your Desktop OS? Windows 11

• What's your Seamly version from Help/About? Seamly 2023.2.12.2224

[DSCaskey]

I'm guessing this is related to that stupid "inUse" tag. The path is probably getting decremented, but the inUse is not getting cleared so the app thinks the tool is still - well in use.

Solution .. get rid of the whole "inUse" flag... for any tool - it makes no sense.

[slspencer]

The 'In use' attribute is basically a hack to replace a recursive search through the file for occurrences.
Removing it may solve this problem, or it might not, but either way the 'in use' attribute's gotta go. It complicates more than solves problems.

So a possible solution if removing the 'in use' attribute doesn't work::

Problem:
Currently if point P1 is used in an internal path then there's an internal path object O1 that contains point OP1 that references P1.
When the pattern piece is deleted the internal path O1 and it's child item OP1 aren't deleted, so P1 can't be deleted.

Solution:
When a pattern piece is deleted, check for occurrences of it's internal paths throughout the file (up & down). If no further occurrences are found then delete the internal paths.

[DSCaskey]

In fixing the pen style issue with Internal Paths and Cutouts, I believe I have solved the issue with the orhaned paths.

When an internal path is created it creates 2 seperate elements in the XML... a "path" and an "iPath" (an instance of the path). The path is used for the scene display, while the iPath is used in the Internal Path dialog path listwidget. When a path is deleted from the list, only the iPath is deleted from the XML, and the path->attribute "inUse" is set to false. Since the path element still remains, it's still rendered in the InternalPathTool paint() routine.

I'm assuming the idea was to be able to reuse a path, but there is no implementation of this. The solution should be to simply remove the "path" along with the "iPath" when deleting., and dispending with the "inUse" attribute. Reparsing will then remove the Internal Path from the piece. I just have to check and make sure using a path / iPath in a Union doesn't cause some other complication.

[slspencer]

Before deleting the Path, should there be a check for additional iPath instances of the Path in other pieces?

[DSCaskey]

There is... in the decrement routine. If the _referens == 0 it was just writing inUse = "false". Instead I just did away with the inUse attribute (it's uneeded as you know the _refrens count) and just removed the < path

. BTW... there is some "garbage" collector routine that's supposed to

cleanup, but it doesn't. Here's though where things are hinky... normaly there is only 1 iPath per per path... ie only 1 path per piece. So the reference count is either 0 or 1. Except with Unions... and that's where things are messed up, which I'm trying to sort out.

…

On Sun, Apr 23, 2023, 11:10 PM slspencer ***@***.***> wrote: Before deleting the Path, should there be a check for additional iPath instances of the Path in other pieces? — Reply to this email directly, view it on GitHub <#870 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHTXADUGTTJEHCRD5KHU7EDXCXVJZANCNFSM6AAAAAAVGCY6RU> . You are receiving this because you commented.Message ID: ***@***.***>