After this one, is compiles with the opt-in macro. Not changed yet,
though.
Change-Id: I29a66ecb5daa71d0d97566b81fd9f47d92f6368a
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Runnable functionality is nowadays mostly accessed more directly
in QtcProcess and its setup functions.
Change-Id: I2a2b5433aef1d464dc58d5a35069376dee051d57
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Use device set inside passed runnable instead.
Grep for all usages of RunControl::start().
If passed device wasn't nullptr, set this device
inside passed runnable. Otherwise ensure that
passed runnable contains device set to nullptr.
Change-Id: I06fd42a16246fa9fedd81eeb47481a217f887cb0
Reviewed-by: hjk <hjk@qt.io>
The main QtcProcess interface is nowadays a CommandLine, with no
explicit references left to QtcProcess::Arguments and related static
helper functions, so it only clutters the QtcProcess class interface
So move these items out of QtcProcess, later potentially to a separate
file pair.
Change-Id: I45c300b656f5b30e2e2717232c855fdd97c2d1d7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This spares us the typical r = runnable(); modify(r); setRunnable(r)
roundtrip and the m_runnable storage that might or might not
be the same as runControl->runnable. Similar for m_device.
Change-Id: I8300260dd8dd7cd395e40bcd3d2ae45089085008
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Code-wise no immediate advantage, but removes the need for the
unusual 'started' signal.
Change-Id: Ie1d99127e8fe1561c35e035894ee5dd4639d3f12
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Amends 3844f59806.
Some
RunControl::registerWorkerCreator(ProjectExplorer::Constants::QML_PROFILER_RUN_MODE,
[this](RunControl *runControl) {
auto runner = new QmlProfilerRunner(runControl);
connect(runner, &QmlProfilerRunner::starting,
&d->m_profilerTool, &QmlProfilerTool::finalizeRunControl);
return runner;
});
hunk disappeared. This here has the same effect.
Change-Id: Ib81a78944145cc2075bfcb931691adf214f3560d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This combines two of the previous three paths to create run workers,
and refers to RunConfigurations by id, not by type where possible
to decrease coupling between the classes.
Only allow "type of run configuration" and "type of device"
as the only possible kind of restriction and require a uniform
RunWorker constructor signature.
Adapt user code to fit that pattern.
Change-Id: I5a6d49c9a144785fd0235d7586f244b56f67b366
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For a long time, probably from the very beginning, a RunControl
was meant to hold (a copy of) data needed for its operation, that was
valid at the time of its construction, to be resilient in cases
where RunConfiguration setting were changed while the RunControl
was running, or to properly re-run with the original settings.
Unfortunately, the task was repetitive, as RunConfiguration
classes had no generic access to properties / "aspects"
and there was was the runConfiguration() accessor (probably
for mostly unrelated reasons in the output pane handling) which
made the idea of just casting that to the original runConfiguration
and access the data directly there appealing, with all the
expected consequences.
This patch here partially addresses the issue by copying some
more of the related data at RunControl construction time and
adjust the using code, avoiding most uses of the runConfiguration()
accessor in a mostly mechanical matter.
Complete removal appears possible, but will be less mechanical
in "difficult" plugins like ios, so this is left for later.
The new accessors in RunControl are very much ad-hoc, leaving
room for improvement, e.g. by consolidating the access to the
run config settings aspects with the other runconfig aspects
or similar. For now the goal is to remove the runConfiguration()
accessor, and to as much as possible fixed data after RunControl
setup is finished.
Next step would be to officially allow construction of RunControls
without a specific RunConfiguration by setting the necessary
data independently, removing the need for the various workarounds
that are currently used for the purpose of faking (parts of) the
effect of the non-existing RunConfiguration or refusing to operate
at all, even if it would be possible.
Change-Id: If8e5596da8422c70e90f97270389adbe6d0b46f2
Reviewed-by: Christian Kandeler <christian.kandeler@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>
It has been an obsolete alias for setId for a while and downstream
uses have been adapted.
Change-Id: I467370aa67054599c7771e8275d28e62ddc461fa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
We don't need it and will dangle when the RunControl drops its workers.
Change-Id: I93e872083a870ad860624509622c5d779e35dfd3
Reviewed-by: hjk <hjk@qt.io>
The QmlProfilerRunner is owned by its RunControl. It will only be
destroyed from the RunControl's dtor and therefore we don't need to stop
the RunControl at that point.
Furthermore, accessing the RunControl there is dangerous because it is
partially destroyed already.
Change-Id: I006e053bb9cd0da23cedb8fedfc46e049b72517d
Reviewed-by: hjk <hjk@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>
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 wasn't really a singleton even before. For testing purposes make the
client/state/model managers accessible.
Change-Id: Ie5efbc47a6b9119495f999e4e05877d4789da407
Reviewed-by: hjk <hjk@qt.io>
This can happen because a run control may already initiateStop when in
Starting state.
Change-Id: Ie872cb1ba5d0ff65eb1c82ff90f9659311e534f4
Reviewed-by: hjk <hjk@qt.io>
Use the URL scheme to distinguish between them, check that in
QmlProfilerClientManager and test all possible combinations of URL
parts.
Change-Id: I6583e5bf18eda0344a299a279c12578c4ebc7ffe
Reviewed-by: hjk <hjk@qt.io>
We always have a port now in advance and can construct the
command line directly.
Change-Id: I12dba553f4ef073d7c5b00477baf9fa0e5596bdb
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It's a workaround, not a proper solution (as indicated by the
SOFT ASSERT: "d->m_profilerState" in file qmlprofilerruncontrol.cpp,
line 144 triggering) The state manager (and possibly more)
is referenced from potentially running run controls, that are ramped
down after the plugin.
Task-number: QTCREATORBUG-18736
Change-Id: Ia20b168fe640c818276a777e1d23feab0cacd565
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
That makes the high level sequence of operation the same as for the
local socket case.
Change-Id: Ib8af2a7826a482e98b75fe00f3c0e672b98886c5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The connection timer was traditionally used in cases where
the application was started without being given a port on the
commandline. These setups do not exist anymore or have been
changed to provide a suitable port on the commandline.
Change-Id: Ib4653e73943819762f0c8162cc13e4da789705a7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We need to start the local server before the application, as the
application has to connect to it. If we use a TCP connection, we will
retry. So it doesn't hurt to start it before the application, either.
Change-Id: I64c24f922040d0ac58fe4f05abffef9ec24e3e9a
Reviewed-by: hjk <hjk@qt.io>
There will be stopDependencies, too, which apply when stopping the
runcontrol.
Change-Id: Id72771d28cbb6b254572c9f93db93e0d054b890f
Reviewed-by: hjk <hjk@qt.io>
A RunControl is re-runnable if all its workers are,
a RunWorker is re-runnable if it's Stopped and unless it
says otherwise.
Also ensure SimpleTargetRunner only reportStop() once
per run and make process error message re-usable.
Change-Id: I73f5fb724d3026ceb81d5e32a3a71b4814b2bca9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It turns out that one "Connection" per RunControl doesn't map
well to the uses we have. Instead, RunWorkers need to know
individually how to connect to the place where they can work,
but they are already specific enough to be able to use a
standard class (like QUrl) as their way to specify the needed
entry point.
In theory one could see a RunControl's connection as an
aggregation of its workers connection bits, but that does
not really seem to be needed in code.
As consequence, replace UrlConnection by a plain QUrl, and also
the HostName connection by a QUrl with hostName set.
Change-Id: I40c97e37779314ac0a77041e864a18eadb78f987
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
Not needed anymore, effectively replaced by RunWorker start/stop.
Change-Id: I7483c841cdd4e05c9e1f7636a27b20ece37947c2
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Having the overall runworker setup closer to the general pattern
allows to re-use SimpleTargetRunner.
Change-Id: Iff151cbebaa6ae6615b933f4277b0581a43d7f7f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
