Doxygen code documentation is now available. You can access it on the web via:
- https://valentina-project.org through the top menu, which links to…
- http://valentina-project.github.io
That… wasn’t what I was expecting, to be honest. I don’t see anything there that would help me write a file spec. Am I missing something?
I did not see documentation that would be useful in writing a specification for the .val .vit or .vst files, however I was poking around on wikipedia and thought that XML - Wikipedia might be useful to you. Also, XML classes for Qt | Works Like Clockwork is interesting. I have not yet identified the specific modules where TAPE interacts with the .vit files, but that seems to me a first step in identifying how xml is parsed and the resulting objects are represented internally. Any major change in the way measurements are represented would have to be reflected there. Sorry I can’t be more specific yet, “real life” keeps eating up my time. 
I editted the page some more, then realized that I don’t understand how things are set up as well as I need to. More work needed, but first some food.
i was reading through old forum posts and came across this.
It makes sense to me that there should be a hierarchy… any point named in the scheme you proposed above should be reflected in the page https://wiki.valentinaproject.org/wiki/Measurements#Body_Points_Diagram
I got on this particular tangent because you used an example “Collar Bone Center” that was not on the list of known body points. The requirement for that particular point is not what I want to discuss. My questions are for @slspencer, and the questions are from the point of view of supported patternmaking systems and “known measurements”.
Does the valentina VPO2 need to limit focus and treat as known measurements ONLY measurements which derive from known body points. (I think the answer is yes)
Is it reasonable to “bound the problem” so that it is acceptable to not spend a lot of time or effort processing custom measurements. (again, I think the answer is yet)
just what I was looking for. thanks
- I agree completely that ‘known’ measurements should be based solely on ‘known’ body points.
- New measurement paths defined using only those points can be considered ‘known’, as they can be defined by the system and thus can be rendered visually and localized.
- There needs to be a method by which new body points can be defined for individual users, and those body points added to the user’s file(s). (For example, someone with a deformed spine might want to add a dozen points that trace their spinal curve.) New points should be able to be submitted to the community for inclusion in the main project.
did you see the process documented further down on the same page as the known measurement diagram? If anything needs to be added to the process that is probably the place to discuss it. I am not sure many people know about of use the “talk” pages on the wiki. In some other open software teams, the talk pages on the wiki are the “go to place” for such discussions.
This is the Doxygen generated documentation from the C++ code. It will help with file format specification. It helps you understand the code in an organized manner. You discover what is defined in the navigation menus, read about it and understand it a little more than before, then if you need further info you search for those items in the code to find what you need.
A standard reverse engineering process will work for discovery:
Start with the first mode, Draw.
Select the first group, Point.
Select the first tool, Point from Distance and Angle.
Find it’s code. The Doxygen docs should help.
The XML write-to-file code statements for Point from Distance and Angle should contain the data you need to create the spec for that object.
Then repeat for all objects in Draw mode.
Track down the XML grammar for each tool, one tool at a time.
Paste what you learn for each on the wiki.
When all Draw mode objects’ grammar is defined, then move to Detail mode.
And repeat for each option in Detail.
This is like reverse engineering the SVG file format spec, but fortunately we’re looking at a smaller problem set.
My poor head is whirling try to encompass all of this. I am totally lost in Dox; it took me over an hour to find ‘Draw’ mode, as you can’t search directly for it, and now that I’ve found it, I have no idea what to do with it! Your directions aren’t any help because they aren’t for Dox; I have no idea what they are for.
I’ve reached the point where I don’t have a clue what I am supposed to be doing anymore. I thought that I was writing up how the ‘.vit’ & ‘.val’ files are structured and what each field means, then adding in how my system would work in a schema. Were did I go wrong?
You ARE doing this. You find that info by reading the code.