That is more evocative. Also avoid some instances of popping up the
general messages pane, which should preferably only happen on direct
user interaction.
Task-number: QTCREATORBUG-24430
Change-Id: I69bb49f84c1486fd32b2a048ca4d76dceb6a0b2b
Reviewed-by: Knud Dollereder <knud.dollereder@qt.io>
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Once we parsed the project initially, subsequent parses typically do not
change things in a major way, so we can expect e.g. run configurations to
stay intact.
It therefore makes sense to allow users to schedule an
application run not only during a build (see 4b92b7ac60), but also
during a parse. Arguably, this is even more relevant, as parsing is
usually not triggered directly by the user, but happens as a side effect
of editing a document or switching a branch. It is then annoying for
users to have to wait until the respective buttons get enabled again.
Fixes: QTCREATORBUG-24986
Change-Id: I1081ccde668eee794c39b96cd0bad5c3aaa580bc
Reviewed-by: hjk <hjk@qt.io>
Fix a clazy warning, like:
Don't call QVector::begin() on temporary [clazy-temporary-iterator]
Indeed, we may pass begin and end iterators for 2 different
instances of temporary vector (shared though).
In addition: use const iterators.
Change-Id: Iac1055d9fc226f1b48ca72ee4f3aab433addfe7f
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Also add some QTC_CHECK to get at least some warning
in case the functions are renamed in future.
Change-Id: Ie4e78855152e9946950603c95fa881755e850c62
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
(cherry picked from commit 165ccb828d)
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
- the var args template for addItems was overkill creating a lot of
instantiations. Use a temporary list instead.
- allow default constructed LayoutItems to be used for an empty cell,
avoiding the use of a QLabel with empty text
- add an addRow({...}) overload as convenience shortcut for
.startNewRow().addItems({...}
- rename startNewRow() to finishRow()
Change-Id: I6d49dacbac3d7acf140ca526884ba1ceeeca2e0d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Classes involved are BaseAspect and some derived classes,
LayoutBuilder and VariableChooser.
This is mostly mechanical, with various include/using changes
to make it compile.
Change-Id: I624a457f3555f102e541c4c71e33a9423af32250
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
For convenience, and use it in some places.
Change-Id: I8f7cb502b37b2fbf4cf2d17cac9c6299558332dc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In most cases they are used directly, so there's not much Base* in that.
Added the old name as alias as porting help for a while.
Change-Id: I494a8a560b8996bcf74915ea3570b504df6a6b4c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
removed the connection from plugin to
QmlMultiLanguageAspect::setCurrentLocale
but calling it directly in QmlPreviewPlugin::setLocale
Does not matter which method is called it will change the right
thing only once because it is checking if it already have the
set locale.
Change-Id: I6cb4b115788adc103481dcda45e3214a0cd73401
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This aspect is only available if the special multilanguage
plugin is available.
Translation changes in that plugin changes this aspect,
which results in environment variables which activate the use
of a multilanguage created sqlite to provide the translations.
Change-Id: I38250b69165eb7ec3e4f82dc34b3cc4ba0a33f8f
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
It was already only one id string with two names. Since it is not
an id for the factory but the id of the created run configuration,
settle of runConfigurationId() as accessor.
The factory and id fields in RunConfigurationCreationInfo were
redundant. factory always implies (runconfiguration)id (but not
necessarily the other way round, in theory different factories
are possible for the same runconfiguration type for different
devices). So drop the id field here.
In one case now factory pointers instead of ids are compared, but
this is neutral there as this happens in a context of a fixed Target,
device and project are fixed there, so id and factory are equally
unique.
Change-Id: I859aa91486a2dd4abfc7369540a3322d6ec6260d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
While importing assets, qml files are generated under the import
path and this triggers files update every time a file is added.
This results into high CPU usage.
Task-number: QDS-1675
Change-Id: Ia0775ef78bbffedfaf2c140365ee31718e7ee3a4
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This is in sync with what qmake and qbs project have.
Change-Id: Id82bbd933a8331c3e2032e5068323c183b2a1814
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Will be used later in LocalQmlPreviewSupport so add also
export and dependencies in the build system files.
Change-Id: Ie5d26e7b89342c3ae3ff682a73194f240b71c21a
Reviewed-by: hjk <hjk@qt.io>
This option enforces the usage of FreeType even on Windows
for the form editor and live preview.
This can be useful when developing for Linux devices.
The option can be eanbled by adding
'forceFreeType: true'
to the .qmlproject file.
Task-number: QDS-1143
Change-Id: I7e749e95584e23202536596ee4f7cdaa09d3a371
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
RunConfiguration::update() is becoming a central place acting on
requests to act on interesting changes, triggering notifications
to "the outside" from there is natural.
Change-Id: I159cb548c159a607e2628a178362987fb37b59e3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Currently diverting to the original Project::setRootProjectNode.
Idea is to focus on the BuildSystem <-> generated tree relation.
Change-Id: I8b20173e364713f0919cf4f8b76a2f79ef8770bb
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... instead of creating the BuildSystem direct. This will help the
shift of BuildSystem owner ship as a Project will have potentially
multiple BuildSystem instances (one per BuildConfiguration), but
still be responsible for creating them with the Targets.
Change-Id: I2dd71c7687ed41af9e42c874b3f932ce704e7ee3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and move context menu action handling there.
This is a temporary measure to be able to move that functionality
alongside the actual BuildSystem to the BuildConfiguration.
There is a lot to be cleaned up left, to keep the patch small.
Change-Id: If4b0820a13b376fc97b70785052924972ce22705
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
