So after playing around with my first build since the move to Git I noticed that Roman must have added some new options to the labels. and it got me thinking again how there are a few fields in the pattern label that kinda don’t make sense. The Size and Customer - both of which I think should be based on the Tape of a customer, not a Pattern property.
Additionally why IS there a Pattern properties menu when there is also a “Pattern” section in the Preferences? Why not just put all the Pattern properties in the Preferences -> Pattern? IMO another example of the schizophrenic nature of the program.
I can’t answer the previous things… But Preferences relate to the program where you can set things up that don’t change from pattern to pattern - they are your normal settings, while Properties relate to the pattern itself. Whether you use them or not is totally up to you.
Seems to me though that in the prefs->pattern->workpiece - those are properties that relate to the pattern…?
While at the same time in the Pattern Properties you can set the date & time format (Pref) as well as my company name. - items that normally would not change from pattern to pattern…?
Yes, to the current pattern and all others that you will create until you change these settings.
Not only your company name, etc. but also a reminder as to who you designed this pattern for. What if you were designing for Princess Kate? You should want to record that this pattern is specifically for her because you wouldn’t want to lose her business by using the same pattern for someone else. While in about 5 years from now, it may be okay to use the pattern for someone else.
The one is the path on you PC where you want to save your patterns & the other is the path of the pattern. I’m sure the Powers that be would seriously consider new names for these if you suggest it.
I agree with @Grace , we have global settings vs pattern-specific settings and it makes sense to separate them. The distinction between global and specific made by dismine was well tought and also (sometimes) discussed with others.
But @Douglas you’re right, If it’s confusing for you it will be confusing for other people as well. We probably should get an overview of the global and pattern settings we have and mark the confusing ones as such and think of a renaming. In this overview we could also give a few examples as to why it’s global vs pattern specific, just like the examples Grace gave.
Some documentation / renaming would erase the confusion.
I believe it is good practice especially when talking to someone new to the forum to be sure to find out what version (including date of build) they are using. The platform may also be important.
Thanks, I fought very hard to distinguish global vs pattern specific details.
The Size and Customer fields are good when you run a costume shop. If you plot out a given pattern for an entire chorus you could mix up the pieces if you printed the patterns without the “customer” name.
Also if you are plotting out a range of sizes for a given pattern onto Oak tag to send to your commercial fashion customer, you will be helping yourself and your customer if each piece is marked with “customer” and “size”. This customer may not want your company name on their pattern, but they will want the pattern number and/or pattern name.
And if you are creating patterns for individuals then your customer will appreciate having their name on the pattern, and the date. Because if a customer makes their own clothes, they’ll be aware of how much their body has changed since the pattern was printed. Similar benefit if you make patterns for yourself – the date can be invaluable.
Ok… somebody correct me if I’m missing something here… here’s what the last ver before the split with Roman (and the current git)- it makes me think the new name of the project should be “Sybil”… Why… why… why would you duplicate the same functions in Preferences and Pattern Properties? Sorry… but IMO there is a lot of sloppy code in the project, And this is just one example.
The size and customer - or in my case the actor - should come from the measurement form - NOT a global preference… especially when you have 1 pattern and 20 actors using the same pattern in various sizes. I’m already putting sizes and names in a measurement form - why should I have to change the prefs in - oh say 20 pattern prefs? I should be able to pick ANY pattern… load in 20 measurements and PRINT… and voila each pattern piece should have - My Company, Theatre/Production, Actor, Size, Date. WITHOUT changing ANY preference or template.
Good news! The size and customer come from the pattern preference not the global preferences.
And yes these should default to values pulled from the currently loaded measurement file.
like @KeithFromCanada wrote, in the global settings, it could be called “default …”, because the value set in the global settings will be used as the default value for the pattern properties.
Let’s say if most of my clients need the format dd/mm/yyyy, I would use this as a global setting, the patterns would have by default this format. I wouldn’t have to take care of it.
And for a special customer who need another format, I would set it in the pattern properties as needed.
It might seem like it’s twice the same but it’s not.
At the risk of seeming too pendantic is it time for a data dictionary? I don’t want to create too many constraints. I do want to create a tool because once the project evolves to be bigger than will fit in a single person’s head it is good to write some things down in a place everyone uses.
There are many attempts to define what is a data dictionary. this is one that I found to be simple, useful, and not require a university degree to understand. What is a Data Dictionary?
Perhaps a simple spreadsheet or wiki page where people could record the name and description of an important data element when we stumble over it. Perhaps a tool exists and I have not yet discovered it (Doxogen maybe does this?)
I had already intended to include a data dictionary as part of the file format spec. One vital field is a description, so you know exactly what a variable/element/object/etc. does/is for. As a bonus, said description can be used for tooltips.
…and while hovering for tooltips is okay, I would prefer to also have the in the top right of the window, that when you click on it, causes ‘hotspots’ to show up that give detailed information when you click on them, including links to the users manual/tutorials/etc. In short, if you don’t know what something means or how to use it, full, contextual help is available.
Well done 
in the top right of the window, that when you click on it, causes ‘hotspots’ to show up that give detailed information when you click on them, including links to the users manual/tutorials/etc. In short, if you don’t know what something means or how to use it, full, contextual help is available.