Select to view content in your preferred language

Is a Layer "delegate" type supporting Qt's models in the workings?

2977
3
Jump to solution
09-18-2015 09:35 AM
MarcoPiccolino1
Deactivated User

A layer supporting the model-view paradigm would greatly improve application structure and logic optimization.

0 Kudos
1 Solution

Accepted Solutions
MarcoPiccolino1
Deactivated User

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?

View solution in original post

3 Replies
LucasDanzinger
Esri Frequent Contributor

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

0 Kudos
MarcoPiccolino1
Deactivated User

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?

LucasDanzinger
Esri Frequent Contributor

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