| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
And fix up some incorrect qmake project files
Pick-to: 6.0
Change-Id: Ia6d27ac68195635021fe7c4a5f06386a60f3f323
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the main API of the Dom model:
The idea of the Dom Model is to expose a simplified an uniform model,
while keeping typed objects (as one is used in C++, and ideally using
the modern C++ approach with containers, and avoiding manual memory
management).
In particular this approach avoids reducing everything to an untyped
model.
The central object in this is the DomItem, it is a value type that
keeps a pointer to the actual element.
A non empty DomItem always keeps some context (a canonicalPath)
and one can explore its containers and its contents.
Non existing or missing values simply translate to empty DomItems
and one does not need to check at each step for invalid things.
See the DomItem documentation for more information.
The as() ad ownerAs() templates let one cast back the DomItem to
the underlying elements.
To expose an element with minimal effort one has to mainly implement
the method iterateDirectSubpaths(), and iterate through all elements
contained in that element (see the documentation of DomBase for more
details).
Containers, simple data and references can be wrapped in DomItem
elements just when accessed, so the underlying C++ object can use the
usual containers/datatypes.
A good model should not just be easy to browse, reference and extend
with new elements, it should also have a clear parallelizazion/
multithreading policy.
This is less relevant for a single pass compiler, but for is relevannt
for a code model.
The fact that the current code model now somehow works only from the
GUI thread show the importance of a clear policy when multiple people
can contribute.
In the Dom model there is the following idea:
- During build time pointers to the elements can change (MutableDomItem
should be used)
- Access to sub elements normally has no locks, they should be either
accessed by a single thread or immutable.
- OwningItem are the unit of multithread safe updates, the have a
mutex and protect the parts that need protection
- A DomEnvironment can refer to a parent Environment, perform several
changes (in a separate thread), and commit them all at once (in a
sparate commit).
This commit contains all the main API, and tests for it.
The bulk of the concrete element will be in followup patches.
Task-number: QTBUG-74840
Change-Id: I9e14e8560e3b4aa3268a733fed37e9090c18e3ab
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds more groundwork for the Dom library.
QQml::Dom::Path represents a path in the Dom model.
It goes from an element of the Dom model (DomItem) to another.
It can be created either from a string, with the path static functions
or by modifying an existing path
Path qmlFilePath =
Path::fromString(u"$env.qmlFilesByPath[\"/path/to/file\"]");
Path imports = qmlFilePath.subField(u"imports")
Path currentComponentImports = Path::current(u"component")
.subField(u"imports");
This is a way to refer to elements in the Dom models that is not
dependent from the source location, and thus can be used also be
used in visual tools.
A Path is quite stable toward reallocations or changes in the Dom
model, and accessing it is safe even when "dangling", thus it is a
good long term reference to an element in the Dom model.
In this commit the element of the Dom Model (DomItem) is represented
just by a stub object, it will be added in a subsequent commit.
This commit also introduces the ErrorMessage object.
ErrorMessage is an object used to represent error, warning and other
messages in the Dom model.
Errors are grouped by tags (ErrorGroups).
ErrorMessages might have a unique identifying string (using a number
in a base library that cannot have a list of all possible errors does
not work well.
ErrorMessages should be localized and *can* be pre-registered, but
do not have to be.
ErrorMessages can be associated with a QQml::Dom::Path, a file and a
Sourcelocation. The path (if present) might allows one to show errors
also in more visual tools.
Task-number: QTBUG-74840
Change-Id: I77fb4b78e15ba3674d74937106d40dba4076cedc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
|
|
The goal of the Dom library is to provide a nicer to use basis for the
Qml Code model, to be used by the various QML tools, the designer and
the new compiler.
This commit just adds some common utilities used by the library, to
output strings to a Sink, i.e. a function<void(QStringView).
This allows writing without allocations of extra temporary strings.
The more interesting parts are added in subsequent commits
Task-number: QTBUG-74840
Change-Id: I8fa43d5b622f59c8761b2469551127c0508c23c3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
