I was just now trying to delete just an internal path, (because it proved to be mis-scripted,) & it disappeared, but didn’t delete from the file.
I assume this is because one might be using an internal path for multiple tracings? Is that even possible? I haven’t played with internal paths much.
I was able to eventually figure out how to extract the internal path from the VAL
I think there’s a better way to handle internal paths, and this requires a big discussion about the .val file format. For now, removing all of the xml of the deleted pattern piece is the right thing to do.
Especially with the alterations that @Douglas has spoken of, (selecting the tracing before choosing the internal path, rather than after, as it currently stands,) that’s the only solution that makes sense when the tracing is being deleted.
But what if it’s only the internal path from the tracing that someone wants to get rid of?
As it stands at the moment, unless I’m missing something, it is utterly impossible to delete internal paths without a texteditor. The delete option merely throws them into a limbo of being undetectable except by the inability to delete nodes that support them.
So,
I favor what I consider to be the better solution in the short term, unless that can’t be done without the best solution being decided, in which case I’ll be content to work with the easy solution for now.
Summary:
If coupled with the removal of the ersatz delete option from the internal paths dialog, this is a satisfactory solution for now.
I just deleted an internal path… Saved the pattern and loaded it back in no problem??
Yes you can use the same points to create multiple internal paths, and no it did not pose a problem creating a second piece using the same draft block above, adding an exact internal dart path, and deleting the Waist Dart ipath from the 1st piece.
I would probably tend to agree, but remember any time the schema is changed we have to be aware of what effect that will have on the ability to convert from a previous version so as to not break the older patterns. If we didn’t care about older ver patterns there would be no problem changing the XML schema.
The “pattern piece” being everything between a < detail>… < /detail> block and modeled objects such as < point> or < paths> that the piece uses. Can I presume the 2nd part is NOT happening and that’s the problem of the topic? In other words - using your included example - should not the modeled points id= 12, 13, 14, & 15 be deleted and not just tagged as "inUse=“false”? In other words - what’s the point of inUse - it’s not like you can make those points inUse=“True” once the piece (detail) is deleted - right?
To delete an internal path, delete the <iPath> element in the <detail> section and the elements in the <modeling> section., as a temporary fix to stop file crashes.
Is it possible to:
Update the “Internal Paths” tool in Draft mode to open a dialog which lists all internal paths for the current Draft piece, creates new internal paths, and edits existing ones. If an internal path is not referenced by a workpiece then it can be deleted.
Change the XML schema so that the original Internal Path <path> elements from the <modeling> section move up into their own section, and a new <mPath> element is added to the <modeling> section which points to the original <path> element. This would allow a single original internal <path> element to be referenced in multiple <modeling> sections. It also means that an internal path <iPath> can be deleted from a workpiece without deleting the original <path> definition.
Update the workpiece Options Internal Path tab to select Internal Paths from a dropdown list of all internal paths applicable for the current workpiece. This tab would not allow editing of the original internal path (that would be done in Draft mode’s “Internal Path” tool), but would allow selecting the linetype.
Yes that’s correct…
But were you able to delete the dart from the draft? Or was the internal path still in the XML of the .val, blocking you?
I will try later tonight.
Possible… but the thing is the iPaths belong to the piece (detail), not the draft. However, The modeled < paths> exist between the draft and the piece. If, we are able to base a dialog on the modeled path, I don’t see why it could then not be used in more than 1 piece, in which case the “inUse” tag would now have a purpose… as it would show inUse=True if it used any pieces, false if not used. In other words more like anchor points (pins) are defined and used. So the idea would be to be able to delete the instance of a path in piece mode, and delete the definition in draft mode ( provided it is not in use in any pieces).
Yes… except replace < modeling> with < detail>. The path is defined in the modeling section, used as an iPath in the detail section.
That would then make sense to me.
Wow, I need to clarify this suggestion better!
Here’s my preferred terminology today:
<draw> element in the .val file for each Draft block.<detail> element. <detail> elements are located within a <draw> element.Background info on the DOM element in the XML *.val file:
<modeling> element and at least one <detail> element in each <draw> element.<modeling> element contains pointers to all objects used to define all Pattern Pieces for that Draft block.<modeling> element is used to create and manage <detail> elements. It enables complex operations like the Join tool.Summary:
Let’s move <path> elements into a separate tag <internalPaths> then insert a new <modelling><mPath> element to create a layer of abstraction between an <internalPaths><path> and any <detail><iPath>s which refer back to the <path>'s id.
This will allow :
<detail>s without changing <modelling> or <internalPath> data, and when we want to delete an <iPath> from a <detail> we set the <iPath>'s visibility to “false”. I think this is why the visibility was an attribute for <detail><iPath>s but it needs one more redirection level (hence the new <mPath> element) for correct implementation.TL;DR - Ok here are the steps to make this happen:
Update the DOM to improve processing of internal paths:
<internalPaths> element to store <path> elements.<modelling><mPath> element to refer to <path>ids<detail><iPath> element to refer to <mPath> idsAdd an “Insert Internal Path Node” tool, and rename “Insert Node” tool 
to “Insert Pattern Node” tool.
Add a dialog to the Internal Paths tool 
with these features:
<path> and <mPath> elements<path>s from <internalPaths>)<iPath>'s visibility is set to “true”<path> element plus <mPath> and <iPath> elements which refer to it.In “Pattern” mode, update the “Pattern / Options” dialog “Internal Path” tab with these features:
<mPath>s from <modeling>)BTW, <modelling> is a pre-definition for <detail>, and this pre-definition step enables complex operations like the Join tool. We may want to add more complex Detail operations in the future, so cleaning up the relationship between <modeling> and <detail> now will pay off later.
Does this make more sense now? 
In this example:
Path id=“102” and Path id=“103” can be deleted but path id=“101” can not.
Deleting Path id=“102” will delete mPath id =“202”, iPath id=“302”, and iPath id=“402”.
Deleting Path id=“103” will delete mPath id=“203”, iPath id=“303”, and iPath id=“403”.
<draw>
<internalPaths>
<path id="101" ... />
<path id="102" ... />
<path id="103" ... />
</internalPaths>
<modeling>
<mPath id="201">
<record path="101"/>
</mPath>
<mPath id="202">
<record path="102"/>
</mPath>
<mPath id="203">
<record path="103"/>
</mPath>
</modeling>
<detail id="300">
<iPath id="301">
<record path="201" visibility="true">
</iPath>
<iPath id="302">
<record path="202" visibility="false">
</iPath>
<iPath id="303">
<record path="203" visibility="false">
</iPath>
</detail>
<detail id="400">
<iPath id="401">
<record path="201" visibility="false">
</iPath>
<iPath id="402">
<record path="202" visibility="false">
</iPath>
<iPath id="403">
<record path="203" visibility="false">
</iPath>
</draw>
I say we need to have a new dock that manages the internal paths. I would use a tree widget 8n the dock, where it would show the modeled paths and any pieces it belongs to as child items. It would allow access to open up the dialog again. In the dialog itself instead of a combobox to select which piece to add the path to, I would use a list of available pieces that you could check off which ones to add it to.
That makes sense to have a separate Internal Paths tool group. And being able to add an IP to multiple Pattern Pieces from the IP’s primary management dialog is appropriate, and dropdown lists are a pain.
Further musing along these lines:
Can we rename “Internal Paths” to something like “Pattern Objects” ?
A Pattern Piece would contain a Pattern Path and optional Pattern Objects.
The Pattern Path tools and Pattern Object tools would be in separate Draft mode tool groups.
Establishing the concept of Pattern Objects may be very beneficial.
In future we will have Draft mode tools that streamline the creation of complex items like Full Darts, Half Darts, Attached Cuffs, Buttons, Buttonholes, Tucks, Pleats, Pockets, etc. These tools could auto-create their Pattern Object <path> and <mPath> elements. This would significantly speed up Draft Block and Pattern Piece creation times.
The Pattern Path tool group would be about the same as the current Detail tool group, minus the “Internal Path tool”.
The Pattern Object tool group would contain tools to create Full Darts, Half Darts, Attached Cuffs, Detached Cuffs, Buttons, Buttonholes, Tucks, Pleats, Pocket Placement lines, plus a Custom Object tool similar to the current Internal Paths tool.
In a similar manner, we could create a new Draft Block tool group to streamline creation of new Draft Blocks using information from the current Draft Block and Draft Blocks previous in the DOM. The Draft Block tools would create common variations of Collars, Sleeves, Detached Cuffs, Pockets, Waistbands and Beltloops, Lapels, etc.
THis thread has moved here:
Oh, wow! @slspencer. What an amazing idea 
This way, we won’t need to add all the nodes for the extra bits to the actual pattern, thereby keeping it a bit tidier. I 
the idea
Hola, esta es una magnífica idea. Brillante idea. Lo esperare con muchísimas ganas. Realmente agilizará mucho el trabajo. Gracias por pensar en todo, y para todos.
Hi, this is a great idea. Brilliant idea. I will be looking forward to it. It will really speed up the work a lot. Thanks for thinking of everything, and for everyone.
Ya esto seria lo máximo!!! 
. Tengo tantas ideas de diseño en la cabeza y a veces la carencia de esto que propones en Seamly, me limita. Es un programa tan bueno, que este detalle lo llevara al nivel 10. La idea de esto que propones la tenia hace un tiempo pero no sabia como decirla ya que no hablo el idioma inglés, y quizás no me haría entender bien. Saludos y muchas gracias por todo. 
This would be the best! : heart_eyes :: heart_eyes :: heart_eyes :. I have so many design ideas in my head and sometimes the lack of this that you propose in Seamly limits me. It is such a good program, that this detail will take it to level 10. I had the idea of this that you propose a while ago but I did not know how to say it since I do not speak English, and perhaps it would not make me understand well. Greetings and thank you very much for everything
You mean like details… symbols (grainlines, notches, buttonholes, drill marks, circles, squares, zippers, etc), text, labels… and internal paths - AKA in AAMA / DXF terms - “internals”: lines that are not cut, and “cutouts”: internal lines that are cut.