There sould be some Model to mediate representation of KML as a QTreeView widget

[heltonbiker]

Some information to possibly do that is available here:

http://doc.qt.io/qt-4.8/qt-itemviews-simpledommodel-example.html

[heltonbiker]

The PyQt4.QtCore.QXmlStreamReader class seems very promising to parse KML, specially after I discovered that libkml uses ExPat, which is also a "handler-oriented" parser, and Marble uses exactely QXmlStreamReader to parse stuff, including KML.

The example here is killer, since it does exactely the desired mapping between xml and treeview, and back.

[heltonbiker]

After a lot of reading, the two main sources of confusion are:

• The KML structure itself, specially how (and if) create an object-oriented representation of the DOM or not;
• The mapping between XML (not necessarily KML) to a TreeView so that updates to the TreeView would reflect back to the DOM. QAbstractItemModel class along with QTreeView class should "do the trick".

But most importantly, instead of adopting a big design up front, I think a better approach would be to use Incremental Development based on Acceptance Testing (ATDD). That would involve the following cycle:

1. Given a MainWindow already implemented with a tree view widget on a left panel and a slippy map canvas on the main area (and optionally a Properties Panel at the right);
2. Select a given KML entity which representation should be implemented;
3. Define, at the design level, how that entity is supposed to be displayed when present in some KML file. That would be the Acceptance Test for the entity type:
   1. On TreeView, how is the item to be displayed? What Label? What description? What Icon? Any checkbox? Any button? What should be its context menu?
   2. On MapView, what should be displayed? Any geometry? Any styling? Any interaction? Any context menu, or baloon, or property panel?
4. Implement just enough code to pass the acceptance test;
5. After the acceptance test for that entity is passing, refactor as needed, and repeat from item 2;

That would probably require that the higher-level elements (Document, Folder) be implemented prior to the lower level, typically more deeply nested ones (Features, Geometries, etc.)

[heltonbiker]

This is very interesting reading about the "conceptual gap" between QAbstractItemModel and QGraphicsScene:

https://invalidmagic.wordpress.com/2009/12/10/qgraphicsscene-used-as-a-qabstractitemmodel/

As I see it, a viable alternative would be to have one, yet-to-be-defined "MapModel", which in turn would contain one property of type QAbstractItemModel, and another of QGraphicsScene. Both would be bound to an underlying authoritative data-model, and manipulations would be somehow synchronized between both model structures - one for the TreeWidget, other for the GraphicsView.