Thanks for the feedback Grace. As far as the circle on the dart point … I assume you’re talking about a symbol? I’ve got symbols, buttonholes, and text in the works. I had a symbols tool working, but I wanted to do a standard “On Fold” symbol with the arrows and text, but it wasn’t doing quite what I wanted, so I had to rethink it. Which will be better in the end as I will implement a symbol, buttonhole, and text tools to act like the grain lines and labels currently do. Instead of being statically anchored (pinned), you would be able to anchor an item or let it float, as well as resize and move it. The buttonhole tool would allow you to set the number of buttonholes, the spacing as a specified distance (or to fit between two anchor points?) , and the width. Text should be obvious… you should be able to put text anywhere besides the two given labels. Text like “Gather here”, “Lengthen or Shorten here”. Graphics in or out of a text item is a possibility too… but of course if the pattern is to be plotted vs printing it would have to be a vector gfx - like an svg. Would be handy for logos. Once I have one tool working - like the symbols - the rest can fall into place by following the same template.
Anyhow… should have an initial notch improvement ready to go next day or two. Should have been done yesterday, but found myself going down rabbit holes making my code work with the Seamly code. Plus addressing issues I wasn’t concerned with for myself - like being able to convert and load previous version patterns. For example there is no longer one line, two line, or three line passmarks… it’s now a slit notch with a count of 1, 2, or 3. I had to make those conversions. Now you can select a notch type, subtype, the length, gap width , and a count (1-3). I also made it so you can angle a slit notch.
Definitely on my wish / to do list as well as a “marker” module. Most users are not likely to need to plot out a full scale marker, but I’m thinking along the lines of being able to scale the marker layout for instructions.
And being able to print out nested patterns is a no brainer… just it’s gonna take some thinking on how to handle lists of pattern piece lists, save and load it all, etc.
Off the top of my head, I think one option to an internal path notch will have to be deciding which side of the path to place the notch. It’s been awhile, but thinking ahead, I think that’s one reason I added a notch angle… using 180 deg would flip the notch to the other side.
Programmatically I can see either repeating the method to create an SA notch using an internal path, or maybe reworking the current SA method and pass it either the SA main path, or an internal path.
Hmmmm… I just thought of something that would be a quick way to put a “dot” or “squares” on the seam line… create a new dot & square notch types that simply draws a circle or square at the node point. The radius would equal the length, for small or large dots and the square would use the length as the width. The count would be constrained to 1.
Of course this would be useful to denote say the gather on sleeve caps that match dots on the bodice.
Which then brings up another question that I’ve though of as I’ve added the notch improvements to Seamly… currently the program allows you to select whether the seam allowance is added, or built in. If it’s built in, notches can only go on the cut line. If they are added you have the option to show the second notch on the seam line… which is what we would want to add a dot, as you would not put it on the cut line. As it it now, there is no option to show ONLY the second seamline notch.
Therefore, would it make more sense to have two options… one for the second seamline notch, and added one for the seam allowance notch? And in the case of using a built in seam allowance which would disable the seam allowance notch, an added notch “offset” attribute would allow the dot / square to show on the seam line that doesn’t exist. Does that make sense?
Of course this can also be solved by implementing symbols and anchoring them to node points on the seam.
I’m not able to “actively” participate this discussion as I can’t code (at least a usable language, I just know a bit of SQL and very few VBA), but I’m amazed at the creativity that’s yours I keep reading hoping like a child before Christmas Eve… Please keep on making my dreams come true
Vice-Versa… Understandable. If there are any thoughts you have on this (or any other) topics please feel free to let us know.
My goal will be to use my 40+ years of drafting & pattern making experience, take what I’ve learned playing with my own version of the program, and improve the user experience and work flow of the Seamly2D.
While you may not know the down in the weeds programming stuff with the program, you may say “I wish…” which could lead me to one of those insightful moments and think to myself “Hmmm… AHA”.
Hi folks… After getting stymied on the first few attempts - OK it was more like 1/2 dozen - to be able to convert pattern vers 0.6.0 and earlier to a new ver 0.6.1 schema… I finally conquered the issue of replacing the last vestige of “passmark” in the program & .val XML pattern files. I’ll save y’all the details, but in a nutshell you have to parse though a DOM doc to find and replace all the occurrences what you need to change. I got hung on replacing instances of passmarkLine=" one, two, or three", inside a inside a or a … then replace it with notchType=“slit”, and add the corresponding notchCount. Suffice to say running Qt Creator in debug mode with lots of debug messages was indispensable in tracking the flow through the multiple nested loops in the ver 0.6.1 convert routine.
So… Onto the cool stuff.
New Notch features will include:
Solving the issue of this topic - YEA!
Convert the “passmark” related XML file tags to “notch” tags, as well as a few other minor incorrect / inconsistent text & tags. (t)ypeLine becomes lineType (consistent with lineColor) , and “hair” (a line weight not a line type) becomes “solidLine”
Notch types U Notch, V External, Castle, and diamond are added.
A notch count of 1, 2, or 3 for any type - consistent with the industry standard of front, side or back notches.
Addition of user provided notch geometry for length, width, and angle attributes for a notch.
Addition of Show notch on seam allowance - which now allow you turn on / off either notch.
Addition of configuring the notch length and width in the app->pattern prefs, with reset buttons for the attributes in the geometry groupbox.
Improvement to the visual look of the path list widget.
Addition of buttons to move a list row up, down, top or bottom.
Removal of the annoying do nothing mysterious “?” on the Work Piece / Internal Path Dialogs window title bar.
Addition of the pattern piece and internal path tool icons to the respective Dialog window title bars.
Addition of the “Status” label on the path list widget in the dialogs
Here’s a look at the old vs new Workpiece Dialog: Note how now the path list shows icons for the notch type or whether a curve is reversed or not. I chose to keep the strike through for the exclude or not for a path item .
Here’s a look at the test pattern I used. Around the seam allowance going clockwise… A6 is a slit shown only on the seam, A7 2-T notchs only on the allowance, A8 3-external V 's on both, A9 a castle notch on a seamline with ZERO seam allowance, A10 a rotated slit notch on seam only. A11 is a single diamond on the allowance. NOTE: I disable the rotation for all type but the slit notch as any of the others can get real messy looking. Length and width is limited to 5". This could be changed if there is a valid reason to do so??
Example of the subtypes… Note: When choosing the bisector or intersection subtypes the notch type defaults to a slit notch. Any other type are generally not needed in these subtype cases. Future updates to Notches should include implementing the various button exclusions between types and subtypes.For ex: If a user selects Intersection, the type should visually change to Slit, the rest greyed out, and Count set to 1.
Finally I created a layout of a pattern piece just to make sure the notches are displaying correctly.
That’s all for now… more improvement will be made in the future.
Agreed. Symbols will be coming in the near future.
The Aha moment came though when I realized it would be real easy to add dots, circles, triangles or squares as a notch type to a path node as opposed to adding symbols along the way the grainline & labels are implemented, where they can be anchored (pinned) to a special point vs a node point included on the path. With a grainline there’s the added step of making an existing point a “pin” in the draft (draw) mode before you can anchor the grainline in the detail mode. It’s redundant work… a point already has a name… why the added step to give it another “pin” name? Where on the other hand, you can make any node point on a path a notch in detail mode. Did I make sense?
Anyhow - That said… the fact that Grace kinda got me thinking “inside” the box, I may have some insight into doing away with adding “pins” one at a time in draft mode and allow details - grainlines, labels, symbols, text, buttonholes, etc to be anchored to anypoint on a main path, an internal path, or list of points added in draft mode.
Just checking a few more things to make I’m not missing something before I push the changes mon evening for review. Of course I keep finding more “defects” with other stuff in the process. Taking more TODO notes. There’s probably going to be a long list of issues on Github.
I see in the picture that “passmark” types were already marked, & know that reversed curves were marked as well, (as a negative node, at least in 0.6.0.1.) However, your version is a clear improvement. The only part where I’m not sure of the improvement is that the curves are both marked with the same kind of mark, so it isn’t instantly apparent that one is reversed. Maybe if they were different colors? Red for Reverse, perhaps? Though I wouldn’t want to make it difficult for the typical color-blind person either.
Anyway, that’s my 2¢. Overall, I must say that I love it!
Hi @Douglas! Steve, my SO, is a Linux Kernel engineer and wants to backport our code bases together!
He has expertise in merging code bases and is happy & ready to do this. As a result, we’ll be caught up with you, and when additional changes are made here you can easily incorporate them.