Adding support for CMake as well as QMake
Task-number: QTCREATORBUG-17308
Change-Id: I615b58921918ec87f935e0f11d3dd23ec20f0ac1
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
... and use in as replacement for RunConfiguration::addRunWorkerFactory.
It is still convenient to have a simple way to set up run worker
factories for the typical "just run for this configuration" case,
but it's even better if it follows the nowadays predominant pattern
of keeping factories in the plugin's pimpl.
Also, it turned out there were two copies of
QmlProjectRunconfigurationFactory code, one is enough.
Change-Id: I0b28c4ea18d0f52165a49f6133dc8687a3b9c7cf
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Also, construct the KitManager implicitly when the first
KitAspect is created. Ramp-down is still explicit and
somewhat odd.
Change-Id: If1506e1d0789ecabbaad2d8008851d0b42c5218b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The infamous "build dir is not at the same level at source dir" warning
for qmake projects has gone through a number of iterations in Qt
Creator, having been added, removed and re-added, always to the
criticism of some users. Our new approach is as follows:
- The warning appears at the widgets where the build directory is
set, both in the target setup page and the build config widget.
- The warning also appears in the issues pane, but only if the build
failed.
- The user can disable the warning altogether in a newly introduced
qmake settings page.
- This option is disabled by default on Unix, because to my
knowledge all failure reports have been for Windows hosts.
This should finally please everybody.
Fixes: QTCREATORBUG-16945
Change-Id: I638be1f15e8c260a5d72047d6850a3a0f685cf03
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
There are two differences that get introduced by this change:
- The configuration widget checks that there is a build configuration,
but not if this build configuration is a QmakeBuildConfiguration. This
should not matter, since Qmake is still the only supported project
type for the qmake specific make step
- It removes the automaticallyAddedArguments(). As far as I can see this
never had any effect anyhow, though. They were never actually added to
the arguments.
Change-Id: I73be227a32117e462def38bdd040dbd7cbcc113f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
There are currently two types of wizards for creating auto tests:
- Qt Unit Test
- Auto Test Project
Both produce almost identical code in the case of a Qt GUI-based test,
and the descriptions are very similar. This is really confusing.
The Auto Test Project wizard has support for Qt Test, Google Test and
Qt Quick Test. In addition, the documentation only mentions Auto Test
Projects when it discusses the creation of auto tests:
http://doc.qt.io/qtcreator/creator-autotest.html#creating-tests
So let's just use that and make everything simpler.
Change-Id: Ia16c88c462744baa8df3f9e8082cbcad6ad9eb15
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The possibly intented flexibility e.g. to have different project types
share the same idea of a common context was never used, in all cases
we had a 1:1 relation ship between project ids and ids that were used
as context. This led to oversights like the one fixed in 60fb35a2.
This patch here uses the project id unconditionally as context and
drops all context ids. If we'll ever have the situation where the
original flexibility was needed, Project::projectContext() could be
made virtual and overridden were needed.
Also, the context was never modified for any given project, so the
updating machinery is not needed.
Change-Id: I3f7fac0ed5e4704e126558987c48577f26082dfd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Do no longer expose Nodes from the SessionManager's API. These are now
exclusively handled by the ProjectTree.
Change-Id: I585c2ac919462073870363436e767640775d9045
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Enable Build File for source or header files only and
de-duplicate the corresponding code.
Before, the menus were incorrectly enabled for e.g. .pro
and .ui files also: While the menu was already hidden for
these non-source files in updateContextActions(), the
following call to updateBuildFileAction() did enable it
again.
Task-number: QTCREATORBUG-19098
Change-Id: I87f40e64ab044b33be9c465d1c5dfa36c3cf1260
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
That should save some memory per node, and since creator has a lot of nodes
(e.g. opening the LLVM project adds about 1 000 000 nodes) this should be
noticeable:-)
Calling update inside ProjectTree::currentNode() and rename it to
findCurrentNode() to make sure it is an still existing pointer.
Also, try to reduce the somehow more expensive currentNode() calls
and sprinkle some const around that usage.
Change-Id: I6a7c5db01a71d53d39544d3013cad557d5b96cdc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Get rid of duplicated code to do such signaling in derived Project types.
Change-Id: I26914a1d751d72ee65c15a7943e0e7f34978f042
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Since the rootProjectNode() containing the parsed files is now nested
under a new project node the main node needs to delegate enable/disable
decisions.
Task-number: QTCREATORBUG-17922
Change-Id: Ie7bb6d6802072a2127b32c0fe51fb25fc1c9c6cc
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
If a session contains an open file, when Qt Creator loads this session on
startup, Build File is invisible, and doesn't work.
Change-Id: Icbc918a4b74f6293d100c04bae0a070d99ce7196
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This got broken when refactoring the project nodes.
Change-Id: Iae4614f4a367cefeba3f70faaf19bc2f8994fb0f
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
- Avoids the hassle of QRC files and manually registering mime types
- Avoids performance regressions because of mime types that are
registered after mime database has been used
- Makes it technically possible to detect that a disabled plugin could
handle a mime type if it was enabled
Change-Id: I373008b1b56e9c6b4853055f20b3eeb112a6eff9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
... and the need temporarily storing them by creating them when needed.
Change-Id: I930dd34bc7682f3d4fb40bd8da132f52ba32414b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This discourages storing the pointers needlessly. The items
are still easy accessible by the static ProjectTree::currentNode()
Change-Id: I3c0cd019e9fdc382afacbc9d9de3b97d5f58ae1e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Re-enable the sub dir actions from the 'Build'-menu when a none project
node is selected in the project tree.
Change-Id: I316079336850409f6cd7479310e3b3438060baf8
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use class enum to shorten the FileType to quint16. This frees up a couple
of bytes per FileNode and we can have many of those.
Change-Id: I3a9ae25059690fefa15305a4268269647d6dc1c9
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This is Heavily Inspired by the Generic project import wizard.
It basically does what we commonly refer to as "Create a dummy .pro file for
editing stuff in Creator". The result is generally more flexible (project
logic can be added to the .pro) and better supported in Creator (.pro
is first class citizen, the Generic project less so).
The qmake/make build steps are currently generally enabled but are only
expected to work for very simple projects like the typical "one file
example for teaching purposes".
Change-Id: I4976c34d423f256ea9f8f9e569c9783d90f380e3
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Do not show "Run qmake" in the menu right after Qt Creator starts up
with no project loaded.
Change-Id: I371734e902b518b6270ca14887db14c254237ba2
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Init all class member pointers to NULL.
This fixes possible crash on exit when dependent
plugin was not loaded (e.g. TextEditor was missing).
In this case plugin's constructor gets called,
initialize() method is _not_ called
and destructor gets called -> crash.
Properly delete dependent plugins on
a plugin which failed to initialize properly.
Fix labels of deleted plugins inside an error dialog
after pressing "Error Details" from "Installed Plugins"
dialog.
Change-Id: Iddc029a0f07dcba2501d734d142fb0e69e9383d3
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Do not use the object pool to hold potential wizards. Register
FactoryCreator functions with IWizardFactory instead and use
those to create the wizards when necessary.
This saves us a couple of cycles during startup since we can now
delay construction of all wizards and it makes us more flexible
wrt. managing the lifecycle of the wizard factories.
Change-Id: I95d6a6dfcdf0fd995e1934a9fefcd96c6a676753
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Use "using Core;" instead of prefixing Core:: all over the place.
Change-Id: I00b50da731bf2b4bf442c587566d11a3ef921834
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Using the new .json wizard engine allows us to get rid of much old
custom wizard logic. As additional benefit for the end user of
Qt Creator, the .qml.ui split is now optional.
Change-Id: I4b5ebcc35a585fad6ebc2e994711ca23e3300717
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Reviewed-by: Thomas Hartmann <Thomas.Hartmann@digia.com>
... and default to C_GLOBAL. A rather common case.
Similar for ActionContainer::addSeparator().
Change-Id: I7f9ba573af201c0a472132d5a494ad17cc4175b7
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
