Annotation styles for Draft

[vocx]

... I still want to add the changes to the dimension object to be able to point to the style, and then we can think about merging it into the PR of Draft Annotation Scales.

I would advice you to create a new pull request if you keep adding functionality or new objects. I think it's better for review, otherwise you add way too much functionality in a single pull request.

Your previous pull request is only about the scale annotation for the current dimensions, so it has a very defined scope. But if you add a completely new object, that warrants a separate pull request in my opinion.

[carlopav]

Here it is! https://github.com/FreeCAD/FreeCAD/pull/3167
Added the indication that will have to be merged after PR #3102.

I have a question: should the Dimension style object try to update the related Dimension objects onChanged or is it better to provide a new function like apply_to_related_dimensions?

[carlopav]

this is the version with apply... it takes some time to do it, perhaps it's better to not do it onChanged.
Thanks for the suggestion of format_object @vocx, works perfectly!

Dimstyle2.gif (548.43 KiB) Viewed 1291 times

[carlopav]

dimstyle container.gif (31.31 KiB) Viewed 1227 times

Dimension style container is done! (thanks to yorik layer container that i copied)

[vocx]

dimstyle container.gif
Dimension style container is done! (thanks to yorik layer container that i copied)

Don't forget to add the files to the CMakeLists and the icon to the resource file so that they are properly installed. Otherwise the Travis tests after compilation will fail every time.

[carlopav]

dimstyle container.gif
Dimension style container is done! (thanks to yorik layer container that i copied)

Don't forget to add the files to the CMakeLists and the icon to the resource file so that they are properly installed. Otherwise the Travis tests after compilation will fail every time.

Yes, I still have to split DraftText and DraftLabel and to derive them from DraftAnnotation.

[carlopav]

We have less or more the PR and it compiles thanks to vocx.
Now, it would be nice, when a dimension is created, that is directly associated with the active style object.
How can we do that? where would we store the active dimension style? (and same for text and label of course)
1- we can't store it in Parameters, because the style is a document object: if we change document, the second maybe don't have the same style object.
2- we can have a dropdown menu in the Annotation/main Draft toolbar.
3- we can just rely on the document tree: the dimension gui tool checks if there is a dimension style object and if it's visible. (current dimension style is the visible one in the dimension style group)

I think we need a variable (?) for the ACTIVE_DRAFT_DIMSTYLE, because i don't really like the Gui command to check the toolbar for the style name...
What do you think?
Maybe it could be a property of the dimension group object... (?)

EDIT:

Code: Select all

	|---- Annotation Styles
		|---- Dimensions Styles
		|	|---- DimensionsStyles1
		|	|---- DimensionsStyles2
		|	|---- DimensionsStyles3
		|---- Label Styles
		|	|---- Room Labels
		|---- Text Styles
			|---- Bold
			|---- Romans
		

In the tree above, perhaps is the Annotation Styles object that can store the values of active annotation styles (Dimension, label, text); this could also improve experience because that style is kept between sessions!

[carlopav]

In the tree above, perhaps is the Annotation Styles object that can store the values of active annotation styles (Dimension, label, text); this could also improve experience because that style is kept between sessions!

Implemented as App.ActiveDocument.DimensionStyles.ActiveDimensionStyle.
Dimensions now are formatted according to the style when created.
Also improved the handling of the DimensionStyleGroup, so the ActiveDimensionStyle is always the visible one, non active styles are automagically turned off.

[vocx]

...
1- we can't store it in Parameters, because the style is a document object: if we change document, the second maybe don't have the same style object....

If I'm not mistaken this is what the DraftToolBar is for. Many Draft commands basically look at this toolbar for configuration of their appearance, meaning line width, point width, colors, and even text size of Labels. These options are stored in the parameters. So, in my opinion, you could do the same and add more options to this toolbar, or even create a new toolbar only for your options.

What you are saying is you don't want that? You want an actual object to hold the configuration? If that's the case, your concept could be extended to the entire Draft workbench, so that there is a Draft object with configuration properties instead of the toolbar. I think at that point it becomes a bit of a discussion on software architecture. Is it better to have a real object? Or to have a toolbar that takes its properties from parameters?

About your DimensionStyle, it should probably be prefixed with the word "Draft", so that it's clear the configuration is specific to Draft objects, and not, say, TechDraw dimensions. It may look clear to power users, but many new users get confused easily.

Code: Select all

App.ActiveDocument.DraftDimensionStyles.ActiveDimensionStyle

By the way, I haven't tested your code so I'm still not exactly sure how all this is supposed to work. Maybe you can again explain your idea because I feel it has been evolving, and since you have closed and opened pull requests I'm losing track.

It's a configuration group, that holds configuration objects, which change how draft dimensions are created, and you can globally change this by using a different configuration object.

And you basically rewrote Draft Label, Draft Dimension, etc. (how many?), to use a parent class which is the one using the configuration set by the configuration objects above.

This sounds to me like two pull requests. One for the rewritten classes with a new parent class, and another one with the new configuration objects. Where would they be located in the Draft structure? Are you using all new locations of the source tree, or adding to Draft.py.

[carlopav]

Perhaps you are right, it's time to recap the changes.

here is a small gif:

Dimension style.gif (651.11 KiB) Viewed 1117 times

file changed are:

Code: Select all

draftguitools\gui_dimensionstyle.py
	new. contains the dimension style gui tool;
	
draftobjects\draft_annotation.py
	new. 
	contains DraftAnnotation, the base class for all draft annotations objects
	contains StylesContainerBase, the base class for all draft annotations group objects
	contains AnnotationStylesContainer, derived from StylesContainerBase to contain all other style groups 
		(to be completed in the future, and not used now)
	
draftobjects\dimensionstyle.py
	new.
	contains def make_dimension_style
	contains DimensionStyle object
	contains DimensionStylesContainer object
	
draftobjects\dimension.py
	splitted from Draft.py, 
	contains make_dimension, make_angular_dimension functions
	contains DimensionBase, LinearDimension, AngularDimension objects
	
draftobjects\label.py
	splitted from Draft.py
	
draftobjects\text.py
	splitted from Draft.py

Every object has its corresponding viewprovider. I imagine to implement in the near future a style object for label and text too.

This is the inheritance diagram:

Code: Select all

DraftAnnotation
		|---- DimensionStyle (EDIT: Dimension Style inherits from DraftAnnotation, ViewProviderDimensionStyle inherits from ViewProviderDimensionBase, so it have just basic annotation object properties, but all visual properties of dimensions)
		|---- DimensionBase
		|	|---- LinearDimension
		|	|---- AngularDimension
		|	
		|---- Label
		|	
		|---- Text
			
StylesContainerBase
		|---- AnnotationStylesContainer
		|---- DimensionStylesContainer

If I'm not mistaken this is what the DraftToolBar is for. These options are stored in the parameters.
What you are saying is you don't want that? You want an actual object to hold the configuration? If that's the case, your concept could be extended to the entire Draft workbench, so that there is a Draft object with configuration properties instead of the toolbar. I think at that point it becomes a bit of a discussion on software architecture. Is it better to have a real object? Or to have a toolbar that takes its properties from parameters?

I think this are two things that can coexhist:
- toolbar and parameters are kept across different documents.
- style objects are document related.
What i'd like is that the document and the styles to be shipped together. This AFAICS is not possible with parameters.
Furthermore, this approach allows to quickly switch between different styles, and to link objects with styles directly.
If no active style object is found in document, annotations are created according to user stored parameters.

Code: Select all

App.ActiveDocument.DraftDimensionStyles.ActiveDimensionStyle

Yes, agree!

And you basically rewrote Draft Label, Draft Dimension, etc. (how many?), to use a parent class which is the one using the configuration set by the configuration objects above.

No, I did just add 2 properties (DimensionStyle to dimension objects, and annotation scale to all annotation objects). And reordered a bit the properties groups. All the rest is just as it was in Draft.py

Final prayer: please dont' make me split it, it would be a pain...