elaborate changed stitches
Opened this issue · 5 comments
Somewhere elaborate the dropped section changed stitches.
thread diagram at the start of the video:
after the video
With the blue stitch below, the change might be obvious, but with both stitches black (as in the video) the change might not be expected.
Write an additional tutorial/trouble-shooting/how-to/FAQ page or a section to remedy not expected/desired change of stitches. Note that the button "initialize stitches" allows the user to decide when to reset or not.
I think in scenarios like this one, the behaviour should be that the stitches are all reset to the default. If the shape of the base tile changes or the definition changes significantly, then the stitches should be reset. The code should be simplified and fixed to handle scenarios like keeping the stitches in the proper place when adding a left footside.
"Significantly" is fuzzy and arbitrary. Algorithms need exact definitions. The button "initialize stitches" allows the user to take the fuzzy decision and decide on a reset or not.
Fixing the scenarios might simplify the functionality, it might increase complexity of the code. Sadly to much of the code already grew beyond maintainability.
Ah! the thread diagrams you posted here explains what's going on.
I actually don't think this is not even worth mentioning on the information page. I think the general assumption is that if you change the tile layout you might have to change the stitch definitions. In the unlikely event that someone would change a successful/existing tiling into a different repeat arrangement, it would be apparent that the stitches would need to be redefined.
I suggest removing that paragraph completely.
The revert to default stitches - which seems logical - might not be the best solution: There is a case where the stitches reverting back to default is surprising (different aspect, but a similar scenario that argues against reverting to defaults), and that is when I try to add a footside to a ground that I carefully tweaked and assigned stitches to already.
No amount of "saving" can help there, and I learned that the order of work is best approached with the idea to finish the pattern, repeat, and the footside before assigning any stitches.
It would be convenient to have assigned stitches be "sticky" when you initialise a new pattern definition with a footside, (but I suspect it would be very messy to deal with old intersections having to "remember" their stitches if they happen to remain in the same place in a new definition and only new intersections to have a default.
A workaround might be to ask the user if s/he would like to "save" the existing pattern first before initialising a new one. This might be annoying for experienced users, so there would have to be a toggle to switch off that reminder.
A whole new can of worms - apologies! (But of the lowest priority... Done (and working) is better than perfect.)
Ah! I'm a little late to the party: I didn't see Veronika mention exactly the same (but in one sentence) - my workaround suggestion might help ?
The link in the start message points to an old version of the official help page. The section has been dropped but version control (as a part of GitHub) allows to dig up and show the old content. I added more context to the start message.
The too briefly described procedure in the dropped section may help when a foot side comes as an afterthought, or is to be added to a (complex) pattern found in the catalogues.