Gender issues #760

Bug Reports / Issues
1

To pick up on the discussion on the issue…

https://github.com/valentina-project/vpo2/issues/760

Unknown is already an option and has to remain to be backwards compatible.

Correct… at least not directly. When it comes to costumes it’s not out of the ordinary for parts to be played by the opposite gender, and that may indirectly affect how you draft a pattern.

Actually no. There is more involved. It’s also not really an easy or UI issue per se… that is, all that is used from the Qt UI form is the empty box. In order to add any new options for Gender a new vit schema file has to be created, All the case statements have to be updated to read & write the the new elements in the XML vit file. In addition the code that sets the current and verifys the new vit file ver has to be updated. It should also be noted that without refactoring, the option “Unknown” has to remain an option so as to not break any existing vit files that contain it.

At any rate… I’ve already fixed the code to work with new Gender options… just need the time to test the vit file ver verification stuff with earlier program versions.

BTW… Had this been done in Qt Creator as a drop down list widget … it would have been an easy 1 min fix to add options to drop down widget… and the vit file ver stuff would be irrelevant.

2

Hmmm… As ‘gender’ in this context is purely about what measurements/systems to use, perhaps the options should be ‘Male/Female/Custom’. That would make it clear that a particular measurement/pattern wasn’t cut and dried. (i.e. a dwarf or woman with a double mastectomy, for example.)

3

I agree with you Keith. I did some Googling on “Gender type” and “LGBT”. Who knows what other terminology will be invented in the future? “Custom” will cover any other use of Valentina/Seamly. Maybe someone will use it for theepot cosies?? And: why not.

Keep it simple; please.

3 Likes
4

The gender field is to help a patternmaker remember and understand their client better, it doesn’t impact patterns in any way.

1 Like
5

May I ask what the purpose of creating three separate variables is here, instead of creating a ‘TargetForm’ (or w/e) variable with multiple possible values? Could the ‘Custom’ option not allow a user to enter their own value, like ‘Canine/Feline/Equine/Furniture/Bag/Doll/etc.’?

const QString VMeasurements::GenderMale    = QStringLiteral("male");
const QString VMeasurements::GenderFemale  = QStringLiteral("female");
const QString VMeasurements::GenderUnknown = QStringLiteral("unknown");

(From vpo2/src/libs/vformat/vmeasurements.cpp.)

6

Nope… not the way it’s currently coded with the XML and schema file use. Unless the code is refactored, all three of these have to stay as options, or you break existing measurement files that use them. To refactor the code you would have to for ex: follow the same method to add & store various “materials” for a list of options used in the label templates. These options are stored in an ini file… you have to read them for populating the drop box widget and if a new option is added you have to write it to the ini file. Oh… and you would still have to read the vit file and check and add any gender option that is not already in your defined list. The benefit would be that one could type in whatever to add to a list without ever having to worry about updating the vit schema file & associated verification code.

But, like I said from the start we’re probably making an issue out of one that doesn’t really exist.