GitLab

Task-Number: QTCREATORBUG-6365

Change-Id: I19a200e3c811eef83d591f6eacca3e48eb0fba8f
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>

Change-Id: I11501635bc5c17db557ea8379eb63c9d3915a05e
Reviewed-on: http://codereview.qt.nokia.com/1316Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>

Change-Id: I8b73d583be1ee7183f4074bce49d5390e38631a2

Reformat existing documentation to qdoc.

Reviewed-by: hjk

 * Add a DeployConfiguration class to hold settings related
   to deployment.
 * Add BuildStepsList to hold a list of buildsteps
 * Update BuildConfiguration to use BuildStepLists instead of
   manageing lists of buildsteps itself.
 * Update BuildManager to use BuildStepLists in its interfaces
 * Fix fallout introduced by API changes
 * Update .user file to new way of storing settings

Task-number: QTCREATORBUG-1427
Task-number: QTCREATORBUG-1428
Task-number: QTCREATORBUG-1811
Task-number: QTCREATORBUG-1930

 * Use new BuildSteps interface (as seen in ProjectConfiguration).
 * Use new factory to construct/clone/restore them.

Reviewed-by: dt

The pointers can be used to distinguish BuildConfigurations

The project() should in most cases not matter, instead the
BuildConfiguration should. This shows all the information that needs to
move into the BuildConfiguration classes.

Enables users to change which buildsteps get run per buildconfiguration.
Some further tweaks are probably necessary. This is a rather big
change, though it should work. :)

.. and purge unneeded includes.

This isn't a nice fix but the least evil version of a hack i could come
up. The source of the flickering is: We have a deeply nested structure
of widgets on the project pane. If we call hide() on such a deeply
nested widget, it will activate() it's parent layout synchronously.
That will then post an event (via updateGeometries() ) to its parent
layout that it needs relayouting. Which then will post to its parent
layout the same. And for each LayoutRequested, there's a painting in
between. The fix instead calls activate() up the chain until we are at
the viewport. This immediately relayouts everything. This adds a non
obvoius potentially for breakeage if the widgets are embedded in a
different widget hierarchy. But well, that's life.

Reviewed-by: Trust Me

Conflicts:

	src/libs/cplusplus/CppBindings.cpp
	src/libs/cplusplus/CppBindings.h
	src/libs/cplusplus/FastPreprocessor.cpp
	src/libs/cplusplus/FastPreprocessor.h
	src/plugins/cpptools/cppcurrentdocumentfilter.cpp
	src/plugins/cpptools/cppcurrentdocumentfilter.h
	src/plugins/cpptools/cppsemanticsearch.cpp
	src/plugins/cpptools/cppsemanticsearch.h
	src/plugins/duieditor/parser/qmljs.g
	src/plugins/duieditor/parser/qmljsast.cpp
	src/plugins/duieditor/parser/qmljsast_p.h
	src/plugins/duieditor/parser/qmljsastfwd_p.h
	src/plugins/duieditor/parser/qmljsastvisitor.cpp
	src/plugins/duieditor/parser/qmljsastvisitor_p.h
	src/plugins/duieditor/parser/qmljsengine_p.cpp
	src/plugins/duieditor/parser/qmljsengine_p.h
	src/plugins/duieditor/parser/qmljsgrammar.cpp
	src/plugins/duieditor/parser/qmljsgrammar_p.h
	src/plugins/duieditor/parser/qmljslexer.cpp
	src/plugins/duieditor/parser/qmljslexer_p.h
	src/plugins/duieditor/parser/qmljsmemorypool_p.h
	src/plugins/duieditor/parser/qmljsnodepool_p.h
	src/plugins/duieditor/parser/qmljsparser.cpp
	src/plugins/duieditor/parser/qmljsparser_p.h
	src/plugins/duieditor/parser/qmljsprettypretty.cpp
	src/plugins/duieditor/parser/qmljsprettypretty_p.h
	src/plugins/duieditor/rewriter/rewriter.cpp
	src/plugins/duieditor/rewriter/rewriter_p.h
	src/plugins/duieditor/rewriter/textwriter.cpp
	src/plugins/duieditor/rewriter/textwriter_p.h
	src/shared/cplusplus/ASTClone.cpp
	tests/manual/cplusplus/main.cpp

Reviewed-by: Trust Me

It should not be used outside of the ProjectExplorer and is likewise not
exported.