Annotation styles for Draft

[vocx]

...
It would still allow you to take values from a style, then override, but it would make it clear to the user when you are overriding (and therefore NOT using the style anymore) or using a style (and therefore all values become automatic)

Yes, I think this makes the most sense. It's similar to TechDraw. The dimensioning styles are supposed to follow one standard either ISO or ASME, but if you change a property it no longer follows strictly that standard.

Which reminds me, maybe Carlo could implement the same ISO and ASME dimensioning style standards, just to be consistent with what is already there in TechDraw.

[onekk]

Yes it is good if there are some styles that are standard to include them at the top of the list, (and maybe flag them as "immutable"), so a user will find them prior to the custom made ones, maybe copying the definitions and modify them.

SO maybe adding a flag of "immutable", "read only" or whatever you prefer to the "standard" styles will be a good "starting point", if it is not impemetned yet.

Regards

Carlo D.

[yorik]

Good idea... The best way would actually be to implement these standard styles outside of this tool (ex. a CSV file) so it can be modified by the user, or even have them add their own predefinitions...

[onekk]

If you intend to implement the standard styles, integrating with FreeCAD, A CSV file has to be read and then the appropriate fields are to be populate from this file (the combobox, lisbox or wathever is called by QT).

If I guess well, the standard file could be put in the sources, and copied in the user preference directory (.FreeCAD on Linux) so the custom modification could be done in this file, i.e not using the Meta properties for the standard styles, but a user could have his custom styles saved in the CSV file in .FreeCAD and eventually copied across different system (I'm thinking in this case of a engineering or architectural workshop where maybe many people have to share common styles).

Side Note: Python have a decent management of ini file so maybe an ini would be more verbose and human readable and modifiable:

see: https://docs.python.org/3/library/configparser.html

Code: Select all

[Style0]
name = stylename
font = fontname
size = font size
....
[Style1]
name = stylename
font = fontname
size = font size
...
 

Yorik could you gave me some advice or point me to some documentation about:

- FreeCAD file format

- FreeCAD operation involved in "opening" a File.

- I have guessed from some code that when creating an object some operations are triggered by FreeCAD when some operation occurs.


Regards

Carlo D.

[carlopav]

Ciao Carlo,
the best is that you give a deep read to https://wiki.freecadweb.org/FeaturePython_Objects.
In short (please anyone correct me!):
All objects in Draft are feature python.
Their shape and properties are saved in the document FCStd file, but all the python code of the class that represent the object is not saved. So you need to have the workbench that generated the object to be able to manipulate it. Why? because on startup, when an object is loaded, that code is attached to the object Proxy.

So the __init__ method is run just once when you create a new object (and because of that it contains the creation of properties and their default value).

execute method is run when you recompute the object

you can access every other method of the object class by using obj.Proxy.method()

FreeCAD provides several callbacks that you can utilize in your custom objects, for example when an object is loaded on startup, you have the really nice onDocumentRestored() method. If for any reason you want to perform some last-minute action when the restore is almost completed you can implement the method onDocumentRestored(self, obj).

other useful methods are onChanged(), onBeforeChange(), etc

[carlopav]

Good idea... The best way would actually be to implement these standard styles outside of this tool (ex. a CSV file) so it can be modified by the user, or even have them add their own predefinitions...

Thats cool! you are definitely rising the bar! I wonder which will be the relationship between current implementation of parameters and the defaults stored in document and this new CSV. (that's a general question)
It's a question about having the defaults in a separate csv or in the FreeCAD parameters... I would opt for the second one, since it's already there!

A proposal:
a new created Draft Annotation always check if there is a current style in the document (doc.Meta[Draft_AnnotationCurrentStyle]),
if it find the style it use it, if not it creates the style using the Draft Texts and dimensions as default.
we could change the Texts and dimensions tab to something like Default annotation parameters

[onekk]

@carlopav, Ciao to you!

thanks, now some of the mechanics are clear, but for the FreeCAD document format?

Have you read my proposal to copy the "standard" CSV file in the user directory, so say one could define His own preferred styles, or maybe if a poper file is found the user file wil be merged to the internal "standard styles".

I think that maybe in a large office or firm some styles could be distribuited to the various workstations, without having to make them "by hand" for every new installation.

If the single properties are kept in the file, non need to store them in Meta.

But as always is "a matter of taste"

Regards

Carlo D.

[carlopav]

thanks, now some of the mechanics are clear, but for the FreeCAD document format?
Have you read my proposal to copy the "standard" CSV file in the user directory, so say one could define His own preferred styles, or maybe if a poper file is found the user file wil be merged to the internal "standard styles".

This is cool for sure, but I'm afraid my knowledge is not sufficient to tackle this field
It could be easier, if we want to use a csv, to import and export it from default Draft Annotation Parameters in preferences, no?

[onekk]

Yes it could be cool, but I wonder were the standard styles are placed, thinking in example of using portable builds, it is feasible you have a directory where you could dig into and modify files.

With Appimages, it is a monolithic container (I know that is expandable into a directory), it will be more difficult to deploy in example on many machines of say an office.

if the standard file is copied in the user directory during installation, (eventually with a mechanism of checking the version) the local change remain even across updating FreeCAD, a somewhat extablished mechanism would be using ini files, as they are parsed by python itself using an "standard" module, and more information could be stored, say simply a field like this:

Code: Select all

[General]
version=1.0

[Style00]
...

[Style01]

and so on:

The parsing maybe is more time consuming, but I think that you have not 100 styles, it is even difficult to retain the differences, maybe 10 or 20 is a more realistic number., say style 0 to style 9 predefined and immutable and the others user defined.

The proper style is recorded in the FCSTD file, maybe with a version field, maybe internally stored as "style01-v1.0",,simply and not to difficult to parse, usign the standard python split() function.

When a new version of FreeCAD is installed at the first start the format of the "internal" annotation style version is checkhed against the local file and some decision could be made, the standard style are almost never modified, only minor adjustment could be done in the starting phase of implementation.

or maybe only the user defined styles are saved locally and the standard files are retained in the "source code".

If the decision to not to modify the annotation format but to add only a style field is done, there is no need to modify a predefined style, if a new style is needed, the user simply create a local style.

every information is stored in the FCstd file, eventually backward compatile with older FreeCAD, if the mechanism of retrieving information, is done well, the new field is not taken in account, by old program versions.

Hope to have been clear

Regards

Carlo D.

[yorik]

AppImages are indeed not suited at all for development.
If you wish to contribute to FreeCAD, you should definitely need to get used to manage the source code directly. On Linux, compiling FreeCAD yourself is really not hard, and very rewarding

Basically I'm thinking we could have one CSV (or any other format, but CSV is cool because nicely readable on github, easy to edit by users (you can do that in a spreadsheet app), and we use already some here and there in Arch...

I would say we could have a built-in one, shipped with FreeCAD. And a location to look for user-defined one, so users can override styles from the default one or add custom styles.

Basically I would start by building a simple csv file with all the styles we need. Then we can adapt the editor to read them. I started one below as an example, if anyone feels up to the task...

Next we need to work on the dimension object themselves. Basically I see it that way:

- The Dimension gains an AnnotationStyle property (App::PropertyEnumeration)
- On creation, the AnnotationStyle is populated with the styles found in doc Meta (starting wit an empty entry)
- inside onChanged(), if the annotation style is changed to a style, set all the needed properties and turn them read-only
- inside onChanged(), if the annotation style is set to the first, empty entry, all properties keep their value but they become writable again

That's basically all that is needed... The editor will take care of managing all annotation objects found in the doc if it changes something.

Seems good?