Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Properties framework #2857
Keen to hear ppls thoughts and feedback regarding this.
Basically, this implements a system for storing collections of properties and handling inheritance and priority of properties contained with collections.
The motivation here is:
There's a lot still to do, including implementing saving and restoring collections and porting exiting code to use this, but first I'd like feedback on this approach.
Hi Nyall - great stuff so far!
My random thoughts:
@m-kuhn Nice! That's a huge saving, well done!
Back on topic, I've just pushed some large changes to this branch. This ports across the existing QgsScaleExpression (to QgsSizeScaleTransformer) and other data defined classes to properties, and adds a framework for other QgsPropertyTransformers including a new QgsColorRampTransformer for translating evaluated properties to an interpolated color.
With any luck the doxygen comments are sufficient to explain how this all fits together, but please ping me if not!
I've done an initial port for diagrams to use the properties system to implement data defined styling, as a demonstration of how this will work in practice.
There's no GUI for now, but you can set data defined overrides using the API.
Setting a static override for a the diagram background color property:
Setting an expression based outline width:
Field based outline width:
Here's an example of a transformer used on a property. This will transform the value in the 'passengers' field (with values ranging from 0 to 10000) to an interpolated background color from the 'YlOrRd' ramp:
Hey, just crossed my mind that you still have this PR open (and will possibly work on it again in the near future).
Just wondering, did you consider using Qt's property system?
I think they need not to be known at compile time (see the Dynamic Properties section).
Not sure if we are reinventing the wheel...
I don't think there's really any overlap between this and qt properties (except for the name!). You could potentially embed individual properties using Qt's system, but it had no handling of inheritance, collections, etc. The direct getters/setters won't be going away, so it will still be possible to tie QGIS properties into Qt's framework using Q_PROPERTY.
referenced this pull request
Oct 1, 2016
Ok, I've added QgsPropertyDefinition/QgsPropertyDefinitions for handling this kind of thing. Previously property behavior was only defined in gui, but now it's defined up front for each part of the code which uses properties, and gui uses these definitions to control the appearance and behavior of the property override button (the replacement for QgsDataDefinedButton). I'll use this in part 2 to provide assistants for the standard property templates (eg a property defined as a ColorWithAlpha property will show a color-from-ramp assistant, a property defined as a Transparency property will show a transparency from value assistant).
I haven't added default values yet, but they can be added to QgsPropertyDefinition when required. Similarly I haven't added any python sugar to retrieve properties by string, but this should now be possible by using the corresponding QgsPropertyDefinitions. (Although I tend to disagree re using strings here - part of the design here was to avoid arbitrary string use which requires reading the source to determine the correct string value to use. At least with enum values you can easily see all the acceptable values just by reading the api docs).
Ok, done. There's no more QgsAbstractProperty or subclasses, and everything is done in an implicitly shared QgsProperty class. No more pointer use for storing/retrieving properties either. I'm happy with this - it was never intended that custom property types (eg via PyQGIS) were supported anyway, and we can add future types directly into QgsProperty (eg time based property is high on my list). (BTW - if you're wondering about the struct use in qgsproperty_p.h, it's because originally I was trying to use a union there to reduce the memory footprint of the class... I thought this may be possible in c++11 but I couldn't get it to work.)
So apart from the test failures I need to fix (and API break docs to write up), I'd like to merge this now. Part 2 will expand on the UI for defining properties but I'd like this API locked in before I proceed with that. Any chance of a final review?