A layer supporting the model-view paradigm would greatly improve application structure and logic optimization.
Solved! Go to Solution.
I'm thinking about a Layer which supports model-compatible Objects, both derived from QAbstractItemModel, lists and jsons; and delegates responsible for drawing the data.
Pretty much like MapItemView in the QtLocation api, but with support for lists and jsons.
In our common scenario we have a model which is derived from QAbstractItemModel which cointains records that are points of interest and itineraries.
The available delegates should mimic ArcGIS symbols and also allow for custom components.
We represent geometry as a WKT string, so direct support for that is also welcome, to avoid non-optimal runtime conversions.
Does that make sense?
Hi Marco,
Can you provide some specifics about what you are after? With the Quartz release, we are looking to embrace the model-view paradigm as much as we can, and have it working in several places throughout the API already. However, any specifics on your suggestion with the layer type and how it would fit in with Qt's models would be greatly appreciated.
Thanks for the feedback.
-Luke
I'm thinking about a Layer which supports model-compatible Objects, both derived from QAbstractItemModel, lists and jsons; and delegates responsible for drawing the data.
Pretty much like MapItemView in the QtLocation api, but with support for lists and jsons.
In our common scenario we have a model which is derived from QAbstractItemModel which cointains records that are points of interest and itineraries.
The available delegates should mimic ArcGIS symbols and also allow for custom components.
We represent geometry as a WKT string, so direct support for that is also welcome, to avoid non-optimal runtime conversions.
Does that make sense?
Good idea. We have a few ideas on some things we would like to do similar to this. We will look into what it will take to get this done for a future release. Thanks for the input.
-Luke