Hey I’ve noticed my Application preferences aren’t working as they should (Windows 11, Seamly2D version 2023-4.13.1812)
Maybe it’s my setup, so is anyone else having these problems?
In Piece mode…
Internal Path preference is ‘Dark Green’ which works for any internal path in the first piece I define, but subsequent pieces have gray internal paths.
Seam Line preferences are ‘Blue’ and ‘Dashed’, but actual Seam Lines match the ‘Cut Line’ preferences for ‘Black’ and ‘Solid’.
Notch preferences have the ‘Show notch on Seam Line’ box unchecked, but this is ignored - my notches are created on both the Seam Line and Cut Line and I have to manually uncheck the box for Seam Line on each notch.
Here’s the screenshot for Internal Path preferences.
The Color and Linetype settings aren’t working.
Not sure about if the Lineweight setting is working.
Here’s the screenshot for the Notches preferences.
The Attributes section with Type, Color, Length, and Width is working.
But the ‘Show notch on Seam Line’ setting isn’t working.
Confirmed… sort of. I will resolve #1 & 2, but we have to decide what to do with the iPaths.
First let me give some background… the way RT implemented the pieces in Piece and Layout mode is 1/2 arsed. Instead of 1 class to render a piece, there are 2 seperate ways the pieces are rendered in each mode… twice the work.
So while the IPaths color is not updating correctly in Piece mode, it works fine in Layout mode.
In the above example you can see 3 IP’s… 2 of which are orange and 1 bkack in Piece mode, while all 3 are orange in Layout mode. Actually I created 1 IP, saved, closed, opened, and repeated… when you open a pattern tge IP,'s will be drawn in the preferece color… adding a new one will render in black - the default default color. This is because the constructor for an IPath is harddcoded to black… when a pattern is opened all the IP’s are set to the pref color.
So it’s easy to fix that, but that’s not the issue. The issue is that RT made IP’s the only tool that has it line attributes used in Layout mode. As well as the odd check box to make the IP a cutout rather than another type in the drop down.
But that’s beside the point… we can’t have the option to change the line style (color, type, weight) in Piece mode, while using a global pref in Layout mode.
IMO… we should remove the linetype option in the IP dialog, and simply use the global prefs to render the IP’s and Cutouts in both modes. Also I would also remove the Cut on fabric checkbox and add a Cutout item to the path Type dropdown.
Also I might make the type editable in the IP dialog in Piece mode after a path us created. Currently you can’t change the type.
It does if you save, close, and reopen. It’s because the pen attributes are hardcoded in the constructor, which are over written when the piece class is created… and of course new IP’s are constructed after the piece class, so they are not over written until the pattern is reopened. easy fix, but that’s not the issue.
This one’s got me a little baffled at the momment… it’s all wrapped up in that is there seam allowance and is it built in - as all the paths, pens, and brushes get swtiched around depending on the state, but I’ll figure it out.
As far as the Internal Paths and Cutouts, and removing the “cut on fabric” checkbox… oy vey. What should be a simple task becomes another unraveling of the spaghetti. Since the pieces and layout pieces are propagated throughout the code… including the schema and even down to the DXF export… it’s just dumb to have a PiecePath->type describe an Internal Path, while the same PiecePath->type plus an isCutOut flag to describe a Cutout. Not to mention the checkbox is located in a spot that has no relation to the Type dropdown.
To use a juggling analogy… instead of just juggling 2 balls, RT made this like juggling 5 balls.
Well, I resolved the pen issues with Internal Paths and Cutouts, made it so you can edit IP <-> Cutout, but not Custom SA… and vice versa (too much work to convert between the 3), and fixed the orphaned Paths when deleting… but have to fix another related issue I discovered with IPaths in a Union. What else is new. < sigh >. Currently if you have an IP in a Union, and choose to retain the original pieces, the IP is not displayed in the retained piece(s). It’s there, just not displaying. It’s even more confusing, because if you want to delete the IP in the united piece, you have to delete the IP in the retained piece first… but confusing because you can’t see it.
Well… I’m still trying to resolve issues with internal paths in a Union piece. I’ve decided that the whole Union tool has been done really stupid. For now I’m just going to get the internal paths fixed, then at some point refactor the whole Union tool.
While trying to sort out the issues with the Ipaths in the Union tool - I figured I’d give Internal Paths automatic incremental default names in the dialog… rather than the current “Unnamed path”.
Agree