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.
1 Like
Wow, I need to clarify this suggestion better!
Here’s my preferred terminology today:
- Draft mode and Draft blocks. There is one
<draw>element in the .val file for each Draft block. - Pattern mode and Pattern pieces. Each Pattern piece has a
<detail>element.<detail>elements are located within a<draw>element.
Background info on the DOM element in the XML *.val file:
- There is only one
<modeling>element and at least one<detail>element in each<draw>element. - The
<modeling>element contains pointers to all objects used to define all Pattern Pieces for that Draft block. - The
<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 :
- Bettter Internal Path (IP) management, enable deletion of
<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. - Define an IP once for a Draft block then it can be easily added to any Pattern Piece created from that Draft.block. Updates to IPs will auto-propogate to Pattern Pieces. This is the behavior of other Seamly objects, and this should be consistent for all Seamly objects including IPs (and Groups, but that’s another thread.)
TL;DR - Ok here are the steps to make this happen:
-
Update the DOM to improve processing of internal paths:
- Define a new
<internalPaths>element to store<path>elements. - Define a new
<modelling><mPath>element to refer to<path>ids - Change the
<detail><iPath>element to refer to<mPath>ids - Results: Management of IPs occurs in Draft mode. Many Pattern Pieces can be created from a single Draft Block. Each Pattern Piece can display or hide the IPs available to it. Deleting Pattern Pieces won’t delete IPs.
- Define a new
-
Add 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:- “Add New Internal Path” button – Creates
<path>and<mPath>elements - List of currently defined IPs for the current Draft Block (all
<path>s from<internalPaths>) - “Options/Delete” popup via right-click on IPs in the list.
- “Options” dialog allows renaming the IP and the ability to move/exclude/delete nodes.
- “Delete” is disabled if any associated
<iPath>'s visibility is set to “true” - “Delete” deletes the
<path>element plus<mPath>and<iPath>elements which refer to it.
- “Add New Internal Path” button – Creates
-
In “Pattern” mode, update the “Pattern / Options” dialog “Internal Path” tab with these features:
- List of all available IPs (all
<mPath>s from<modeling>) - “Hide / Display” popup option for each IP in the list
- List of all available IPs (all
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>
2 Likes
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.
3 Likes
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.
2 Likes
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:
2 Likes
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
1 Like
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.
3 Likes
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
3 Likes
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.
3 Likes