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>
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>
... 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 hides the explicit use of a QFormLayout from the aspect
interface in a new LayoutBuilder class. That currently works
only on a QFormLayout in the back, but opens the possibility
to use e.g. a QGridLayout as use on the Kits and some option
pages.
The aspects now only announce sub-widgets they like to add,
actuall positioning is does by a new LayoutBuilder class,
also cramming several widgets in an hbox in the right column
of the QFormLayout is done there.
Change-Id: I2b788192c465f2ab82261849d34e514697c5a491
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Do not bother to look at generated files. Currently this makes no
big difference, considering that there usually are no generated files
in QmlProjects. That might change in the future with asset
conditioning though.
Change-Id: Ia773f09343efe5ebb006c69e4f41d724bba42d86
Reviewed-by: hjk <hjk@qt.io>
This had already accessors to all kind of commands, having also
qmlsceneCommand there makes it more consistent and lets us un-export
DesktopQtVersion.
Change-Id: I3ba5a840125b2b1197abb1564b7906571230f2c4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The class uses only one ID from RL at compile time, and after the
move RL does not hard-depend on QtSupport anymore.
Change-Id: I9f8aa6782e45fe998d83ddcc5323c396964bf1fe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Essentially following the scheme used for the various project
configurations. This makes it possible to construct OutputFormatters
by Id only, potentially reducing hard plugin dependencies and
opening the road to have several output formatters per
RunConfiguration/Outputpane/...
Change-Id: I4b5fb6fb6be8b0d9a0859f178bb0effc3398b09e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by a RunConfiguration::commandLine().
That's what is typically consumed, and removes the need for some
custom runnable() implementations.
Change-Id: I7700b12cdd0965802a0add977b432314734a5a72
Reviewed-by: Christian Kandeler <christian.kandeler@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>
Avoid a soft assert and allow using the history completer when
specifying the QmlScene or qmlviewer.
Change-Id: Ibf1ff7f07b9280d211902f6510505fff2bc63abf
Reviewed-by: hjk <hjk@qt.io>
This patch adds support for QmlFileSelector for
QmlProject and Qt Quick Designer.
Task-number: QDS-590
Change-Id: I0cc043d3ec9578008ec879b36fe834b70fb8c5ad
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Task-number: QTCREATORBUG-22244
Change-Id: I38c6527269ba553c0e4734c437f5a6918da729a3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Aleksei German <aleksei.german@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>
... at least logically a bit more into hunks responsible for
one of the possible choices of base environments.
This makes it possible to move code that modifies individual
cases closer to the only place that uses it.
Change-Id: I1c87bb869e04e44b92ff097b0bf25274f93808be
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Will help to streamline *EnvironmentAspect constructor signature,
which in turn will help to have a generic cloning mechanism to
clone aspect data, which in turn will help to finally execute on
the idea that RunControls should be re-runnable in their original
setup and also resilient to changes in the setup while they are
running.
Change-Id: Ibdaca487c1f7ce043e675fd014fe923a70273639
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Mainly to get rid of the QProcess::finished deprecation warning.
Also adjust coding style in the surrounding connects when needed.
Change-Id: I12f9b248c7974b892c4a069356e578e80f8c59e9
Reviewed-by: Christian Stenger <christian.stenger@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>
Unused now, and arguably not a valid concept anymore.
A run control may consist of different runworkers,
'operating' on different systems.
Since the removed RunConfiguration::abi() implementation uses
only public Target ABI, user code could revive that locally
in case it was needed again.
Change-Id: I658c6e88b4a1aec18bf4de91fc86230552bc0710
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Using aspects is the standard pattern nowadays, there's nothing 'extra'
to them anymore.
Change-Id: I446f9d7b1db58a4899e5e44df33ce51f655e7be4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
... into items that can be used generically in project configurations
(ProjectConfigurationAspect) and items that have a choice between
global and project settings (GlobalOrProjectAspect)
Change-Id: I94831237bdbb18c339eb76eba131bf7f928933d6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
To remove the last user of IRCAspect::runConfiguration.
Change-Id: I1390166730112008a4050877f96bb29f274e7ef1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This avoids four uses of IRunConfigurationAspect::runConfiguration()
which is meant to be removed soon.
Change-Id: I7a8f0a09b0a90042b0855b18e5be875bd343268c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This avoids one use of IRunConfigurationAspect::runConfiguration()
which is meant to be removed soon.
Change-Id: Ib394a71b6bb7a6c028fc533656454b94895f6451
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
... instead of directly accessing the owning runconfig.
The removes two uses of IRCAspect::runConfiguration()
which is meant to be removed soon.
Change-Id: Ia713864f2544e3c6741482b2663ee54fd2ee80e1
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Split the remaining manually managed data into a standard ArgumentsAspect
and a new MainQmlFileAspect.
Change-Id: I8a8fe3f4a08d602a7b6e9c9463d3d7de257b6e6c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The actual remaining use was to pop up a terminal in some
setups where Mode == Console, with a default of Gui meaning
"no console". In some downstream uses it was used set to
Console (probably to mean "this helper process does not need
a gui") but then luckily ignored when actually starting the
helper processes.
All cases where the console is useful and requested are
nowadays RunWorkers belonging to RunConfigurations with
a TerminalAspect, so they can directly get the relevant bit
from their RunConfiguration without having it part of
all StandardRunnables.
Change-Id: I1368d5968da5cf672656aebf200ccac8d45335d0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This avoids the "catch all" that leads to conflicts with more specific
setups like the AppManagerRunConfig, and consequently lets us remove
the priorities in the RunWorkerFactories.
Change-Id: I382f00ca7f759eef995ac6fe749bb371ab027020
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's what the base class requires, and opens the possibility to
have several factories creating the same type of run configuration.
Also move ios, winrt and android factories closer to their products,
it's the predominant pattern nowadays.
Change-Id: Iad48152f02a248d22cb18dd435a2fc34d73c7077
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Note that the concept of a single monolithic OutputFormatter per
RunConfiguration (and why RunConfiguration, not RunControl to start
with?) is unchanged and suboptimal as one cannot easily combine
existing use cases, e.g. Python_and_Qt.
Change-Id: Ibeb8191020387324f22ed313230293597f96e36a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
No need to have a dozen lines of code in a separate translation
unit and more in line with what others do nowadays.
Change-Id: I765535d1484805bc3005fe23bfd4992a96a80e9c
Reviewed-by: hjk <hjk@qt.io>
