There are very few reasons to use mainWindow() directly.
Especially for modal dialogs, using dialogParent() is important, since
that guarantees the stacking order in case of other dialogs currently
being open.
Change-Id: I7ad2c23c5034b43195eb35cfe405932a7ea003e6
Reviewed-by: hjk <hjk@qt.io>
More a buildsystem than a node thing in general and removes
one use of activeBuildSystem and one use of the ProFileNode
-> ProFile back pointers.
Change-Id: Ie007fcd0db9e9294a08b3a1cd68f825c7d3dc9b8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This will help collecting feedback from users affected by bugs.
Task-number: QTCREATORBUG-22508
Change-Id: Idfc22245587dd2d71b229b4ab6c7562fb7a5ecfc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Instead, we keep the IDocuments as "extra project files" in the Project
class, like the other project managers do it.
This has two advantages:
- The document is no longer created in a parser thread
callback, improving Qt Creator responsiveness while
loading a project.
- The IDocuments no longer get needlessly destroyed
and re-created on a re-parse.
This is relevant because adding these objects to the DocumentManager
results in the creation of file watchers, which is expensive.
Task-number: QTCREATORBUG-18533
Change-Id: I49c03377974e6b33340234dbabbbd82b8d0c827c
Reviewed-by: hjk <hjk@qt.io>
When parsing larger qmake project, the callbacks from the parser threads
are currently overloading the UI thread, often rendering the application
non-responsive until the project is completely loaded.
This patch moves some expensive operations from the UI thread into the
parser threads, at the cost of a somewhat ugly two-stage setup for some
types of objects.
On my Linux machine, I measured that the time spent in parser callback code
went down by almost 50% when loading the Qt Creator super project.
Task-number: QTCREATORBUG-18533
Change-Id: If9624da5b07e81a50c180693580b20a70e1aaea7
Reviewed-by: hjk <hjk@qt.io>
E.g. for Qnx, QT_INSTALL_PREFIX is not a prefix of QT_INSTALL_EXAMPLES.
Fixes: QTCREATORBUG-22592
Change-Id: I3092cd76af01519783e1162ab8e79caaf0836f00
Reviewed-by: hjk <hjk@qt.io>
Effectively the same approach as for Android, but a bit more ugly
as we don't have necessarily access to the appman plugin headers
even at compile time.
Change-Id: I6d00e69b593470e059a16a1fcf6b57bdd550ae40
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This was implemented rather sloppily: The file was removed from all
variables, but only added to one. Also, no care was taken to insert the
new file name into the same block the old one was removed from.
Fixes: QTCREATORBUG-19257
Change-Id: Ib309389ba7647189112d5c7dd7b3e784f921d2c3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We show all source files in the project tree, including those which are
listed in scopes that evaluate to false in the current configuration.
This is intended, as we want users to be able to navigate to all files,
not just the ones that are part of the build for the current target.
However, it'd be nice for users to be able to tell which files are
"active" and which ones are not. Therefore, we now mark the non-active
ones as "disabled" in the project tree, just like the QbsProjectManager
does.
Task-number: QTCREATORBUG-22855
Change-Id: Icfb48d4f6a247de76fc109acb84b34f03866e754
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
As opposed to qmake itself, Qt Creator tries to resolve the value of
INCLUDEPATH against the sysroot. Therefore we should not reject Unix-
type absolute paths as candidates for sysrootification on Windows hosts.
Fixes: QTCREATORBUG-21164
Change-Id: If4be103061ad3edc64f8d1f5cfeb7c6b48e961c8
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
...without the user having to add them to DISTFILES or OTHER_FILES in
addition to TRANSLATIONS.
Task-number: QTCREATORBUG-7453
Change-Id: Ic9621e66079a52f22272c945b92d183eec852f68
Reviewed-by: hjk <hjk@qt.io>
... when adding and removing files via the project tree.
Fixes: QTCREATORBUG-2196
Change-Id: Ie4ee3a244c9089953cf414d9777fc65b6a8b9689
Reviewed-by: David Schulz <david.schulz@qt.io>
... from a project which are pulled in via wildcards.
Such files cannot be removed from a project file, because they are
not listed verbatim. This kind of failure should not be reported to the
user if the file is also deleted, as the file list will have the correct
state after the next reparse.
Fixes: QTCREATORBUG-22586
Done-with: Christian Kandeler <christian.kandeler@qt.io>
Change-Id: I3dc66fe9a6594be7d0b86f46d830cd099ee49fd7
Reviewed-by: hjk <hjk@qt.io>
Provide general infrastrucure and implementation for qmake.
Fixes: QTCREATORBUG-16067
Change-Id: I8c6368fe2724c9450dcbc3410b6ca459bbbdc043
Reviewed-by: hjk <hjk@qt.io>
We do not introduce another category, but list them under "Headers", as
we do with PRECOMPILED_HEADER entries.
Fixes: QTCREATORBUG-17569
Change-Id: Ie0e6efdd09715daf2802b126a4ecbdc20b25d008
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by a non-mutating .stringAppended, doing the same.
Change-Id: I7adb6cae3415942cc9a80088bd75cda9d577d4a5
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
More consistent with the fromString case and avoiding false
conversions QString -> QFileInfo -> FileName in case the
inheritance of QString suddenly disappears.
Change-Id: Ib14646ab1a660fd45dd1ea6862a0b5faa52ad0e3
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... when setting up extra compilers.
For example, the code model was not able to resolve included ui_*.h
files in a project that wasn't built yet, if the respective FORMS
declaration came from a .pri file.
Fixes: QTCREATORBUG-22395
Change-Id: I75c4b2b38fec209519adb563d579ecd3a17fe042
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When a file is saved, the directory is also touched. If files are not
added or removed, it is not necessary to reparse the project.
Change-Id: I718db68362d41ba936629be880f739ad79b8cb6f
Fixes: QTCREATORBUG-22361
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... in the pro file editor.
When the user selects "Jump to file under cursor" (e.g. via F2), and the
string under the cursor is not resolvable as a local file path, we
assume it is a CONFIG value and try to locate a corresponding prf file.
To this end, we expose the "feature roots" information of the qmake
evaluator in the QmakeProFile class.
Fixes: QTCREATORBUG-15753
Change-Id: Ibdc6e194a40f07030a5d21f2ddc7b92b63d1765b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Under certain circumstances, the file system watcher in the qmake
project parser keeps emitting the directoryChanged() signal even though
there seem to be no changes on the file system. Make sure we reparse
only if the directory timestamp has really changed.
This amends 76262814b6.
Change-Id: Ibdcd1e8405a49e78528bf5903e7caafc371cad1b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The idea is that some of the more intrusive prf files in Qt can skip
themselves when they encounter this condition.
Task-number: QTCREATORBUG-17521
Change-Id: I09a33b2d3c5dee1232803d46c521cc9fd29e1898
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If the user wants to indent with tabs, then consider that when adding
source files via the UI. But try not to mix: If the respective variable
already uses a different indentation consistently, then keep using that
one.
Fixes: QTCREATORBUG-8016
Change-Id: I037c9ac4d4e7fbbe5753a846e57d938bbb440d6a
Reviewed-by: David Schulz <david.schulz@qt.io>
Don't blindly append to the end of the list, but try to put files into
the right place with regards to lexicographical order.
We do not re-sort existing file lists, nor do we attempt to be fancy
with strangely formatted project files. But lists conforming to our own
style will stay sorted, in particular lists that have only ever been
touched by Qt Creator.
Fixes: QTCREATORBUG-553
Fixes: QTCREATORBUG-21807
Change-Id: I15db0e867a2d477fcf95e008f98ba468dcd83e45
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
...for the qmake project manager.
When parsing the project files, remember whether a file was discovered
by the exact or cumulative parse. Only files that were discovered by the
exact parse are considered "active" and thus part of the build
configuration. The others are not offered for selection.
Fixes: QTCREATORBUG-16016
Started-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: I7a28b4de15e048975d7f0cd737dd8c11f744315b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
These are not used during parsing but when operating on the items
in the project tree.
This loosens the ties between the qmake related parser and project
nodes.
Change-Id: I077356fcde240df56b466c71c902c821c4885f6d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The build directory can be "empty" if there is no build configuration,
or if the build configuration's build directory is empty.
Handle both cases in the same way.
This avoids passing an actually empty build directory to the parser,
which the parser does no longer handles gracefully on Windows.
If the build directory is empty, use the project's source path (instead
of QDir(QString()) which is the current working directory), which makes
it consistent with the behavior when actually building in that case.
The parser does not actually write files to disk, so there is no issue
with temporarily using that directory and later switching to a shadow
build directory.
Task-number: QTCREATORBUG-20121
Change-Id: Ia454085edae6b55b445cc5cf0ec3ae1c85464b0c
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
