Details
-
Suggestion
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
None
-
7c5cb036a (dev), 028f59ef2 (dev), e557bba77 (dev), 36218f25d (dev), c5ac46137 (dev), 9db54bd47 (dev)
Description
- MOST of the times (for read def) we use just INFO and we don't need subItems tree or whatever
- QMap<Path, Ptr> m_subItems; ← Typically only subpart of the Path, like "[""]" or ".objects" or smth else. maybe it's actually PathComponent-s
- Looks like foundTreePath and rootTreePath could be removed.....
- Remove ensureItemAtPath ?? same as infoAtPath ? Which I assume thought to be static at some point?
Why AttachedInfo and FileLocations must be aligned hierarchicaly with the Path hiearachy? Like When looking for a AttachedInfo<FileLocation> it's not just map Path - Info, it's tress, where each Node has Subitems etc. Like whatever we modify we are structurally(a.k.a. Path defined) valid?
What we need in most cases just a simple hash map <Path - FileLocations> ?{}
Attachments
Gerrit Reviews
For Gerrit Dashboard: QTBUG-130710 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
604373,8 | QmlDom improve reliability of FileLocations | dev | qt/qtdeclarative | Status: NEW | 0 | 0 |