New properties framework

[bjorn]

I've started implementing a new properties framework in an attempt to improve some existing usability issues as well as to make it easier to add support for list properties (#4002).

This is a work-in-progress! It its current state the Properties view can only edit a few built-in map properties.

I'm sharing this here for the curious and to gather feedback.

[bjorn]

Here's a preview of what it looked like at some point, when it wasn't actually functional but had all Map properties represented:

And here's a video of the current state, with only three properties, but they are fully implemented:

resize-map-button.mp4

Main advantages are currently:

• The widgets can be directly interacted with.
• They can respond to layout (W/H presented horizontally or vertically based on width of view).
• Easy to add buttons like "Resize Map" that are not hidden.
• Huge reduction in complexity / code size compared to existing properties framework (but still lacking features, like nested properties, selection, etc.).

[dogboydog]

I got a chance to try this out and look at the code. I like it. It's nice to have the resize map button more accessible on the map properties.

As far as the code, I'm definitely less equipped than you to judge it but I had a few thoughts.

At first I wondered if there might be a way to define these editable properties and the widgets that would be produced on the edited objects themselves (worlds, maps, etc.) but I guess that's really only used in this property editor component, so there's no need.

The properties have to take the editor factory in as a constructor argument, and currently you are creating a subclass for each type of property. I'm wondering about if there's a way to make it so that only the PropertiesWidget would even need to know about the factory. I feel like the factory could just be a way to generate editor widgets for well-known types of properties that don't need customization. Or maybe the factory just becomes a parameter to addProperty() instead and you only need to provide one if you need to customize the produced widget.

Also, it might be nice if there was a lighter syntax for adding a property that didn't entail creating a class for each property. Part of what makes me think this is the current need to store the editor factory in each property which creates a little more boilerplate for each property, while classes that customize the widget like MapSizeProperty don't actually need the factory at all from what I can see. Being able to just pass in lambdas or something for getting/setting the value to addProperty() could be nice. I would think there would be a lot of properties where you would just be calling existing getters and setters, but maybe I'm wrong.

Feel free to disregard any of this, though, just some initial thoughts that may be misinformed

[bjorn]

@dogboydog Thanks for writing down your thoughts on the new properties implementation! They've been the exact things I'm also wondering about / struggling with. There may not be one simple solution for everything, but indeed this "factory" argument is quite annoying, especially when passing in that "default factory" most of the time anyway.

I've thought about creating the properties through the factory instead. So far there are ValueTypeEditorFactory::createProperty (to create a ValueProperty) and createQObjectProperty. But for now both have remained unused because they didn't quite fit either:

• The ValueProperty keeps a local value, which I thought would be a good way to avoid subclassing. Of course, then signals need to be connected to keep that value updated and respond to changes. I still need to try this approach.

• The QObjectProperty could be even more automatic, since it wraps Qt's meta object system to directly work on a declared Q_PROPERTY. However, currently none of the relevant properties are exposed as a Q_PROPERTY. The closest are those on the EditableMap class, but they're lacking a NOTIFY signal which means the widget's value can't update when needed. I'm also not entirely sure about using EditableMap since it's the scripting API, but it could work out and some people could use the change signals in the API too anyway.

When not using QObjectProperty, another thing I'm not happy about is that each property needs to do its own change signal handling. Hence I'm looking into introducing a kind of MapProperties class, which would own all the map's properties and connect to the relevant change signals instead.

[bjorn]

Small update on the current state. Last week I've finished implementing the built-in properties for all data types, minus a few that will need a custom widget:

In the above we see a lacking widget for setting "Allowed Transformations" as well as for changing tileset parameters (which will use a button for now, similar to "Resize Map").

In the past days I've addressed many loose ends, like setting minimum/maximum values, step sizes and file dialog filters. I've also improved the widget for setting up the font of text objects, so it takes up less vertical space:

The biggest task remaining is to add support for editing, adding and removing Custom Properties, and also to make the headers collapsible. Other open tasks are restoring support for changing the properties of multiple objects at once and displaying "inherited" values like the class set on a tile when a tile object is selected.