PropertyBag (Variables)

[Zolko]

This feature exists as a separate workbench called DynamicData, it exists in Path as PropertyBag and it exists in Assembly4 as Variables: they all do the exact same thing ... and which is a very very cool and useful functionality.

I spent some time comparing them.

Thank-you, I think we don't do such internal comparisons enough

Agreed, but we need to take it to the next step. Consolidating features and removing redundancy is even harder but makes a huge difference to usability.
...
PropertyBag has the most intuitive task panel (IMHO)
...
All three implementation are good. IMHO DynamicData is the best/most complete but I don't think it warrants an entire workbench. The full toolbar and menu is just clutter. The features of all three could be consolidated into a well designed dialog that would be launched from one place.
I'd suggest right-click on the document node and add another item to the context menu after 'Create group...'

Back to this topic: let's assume that we want to make such "PropertyBag" objects compatible between workbenches. How do we signify that an App::FeatrurPython object is actually a PropertyBag ? I suggest to add a custom property to signal this. An App::PropertyString in the "Base" property group, and let's call it "Type", and let's set it to ... well, what ? PropertyBag ? Seriously ? Can we find a sexier name here ?

Code: Select all

variables = App.ActiveDocument.addObject('App::FeaturePython','Variables')
variables.addProperty( "App::PropertyString", "Type", "Base" )
variables.Type = "PropertyBag" 

PropertyBag.png (184.35 KiB) Viewed 1410 times

[adrianinsaval]

PropertyContainer? how does asm4 (or the others) recognize it's own "PropertyBag"? I agree this feature should be in main FreeCAD.

[heda]

PropertyGroup, ProjectProperties, ProjectData, AuxProperties, ModelProperties?

[kisolre]

Not a "Project...". since they are not (and shouldn't be?) global per project and there could be multiple sets of properties.

[adrianinsaval]

maybe UserProperties? since they are manually created by the user I think, AuxProperties sounds good too. Anyway, I don't think the name is too important as long as it gets into FreeCAD.

[carlopav]

I was asking myself if we really need this object if/when realthunder configuration table PR will be merged...
To me It would become al of a sudden obsolete cause - if i got It right - we will Be able to bypass Cyclic referencing and add the properties right into the Part container...

[Zolko]

if/when realthunder configuration table PR will be merged... To me It would become al of a sudden obsolete cause - if i got It right - we will Be able to bypass Cyclic referencing and add the properties right into the Part container...

You're right, let's not do anything and wait for Godot, he'll solve all of our problems

[carlopav]

You're right, let's not do anything and wait for Godot, he'll solve all of our problems

I think this Is a tipical decision that have to take into account a vision... We already have more than One workbench to accomplish such a task. Why should we urgently need another way?

[Zolko]

We already have more than One workbench to accomplish such a task. Why should we urgently need another way?

that's the exact point of this thread: to harmonize 3 methods that do more-or-less the same thing, and make them compatible.

PropertyContainer?

yes, this sounds good. I'll make that the choice for Asm4, hopefully Path and DynamicData will do that too