Interestingly, the contexts were predominantly Qdb::*, standardize
on that. Long term we might collapse RemoteLinux descendants anyway.
Change-Id: Id7009ee6b662d6c29f98e3809619b604aeeea7d9
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
... and re-use the old QtcProcess::readAllStandard* names for
a QString-returning 'decoded' version.
For now, only use that in 'full Utf8' cases, to stay bug-compatible,
the plan is, however, to employ the QTextCodecs we have already
in the channel buffers. That will be one-by-one, though.
Change-Id: Id209e0671920d4ea4197918e872f441254112d52
Reviewed-by: Alessandro Portale <alessandro.portale@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>
A convienience function that leads to an interface that's "too stiff".
Change-Id: Ide2e5fd991707d08690e7e384e9048a30e0828f4
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Move it to its own header.
Get rid of SshConnection and SshConnectionManager,
as they are not used anymore.
Change-Id: I52fe20d7816ea57e7a7158ab2ae9565d50a76e21
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Same function as mapToGlobalPath, but operating on a QString specifying
the local path part. It's the majority use case and arguably the 'right
thing' to use instead of a full FilePath that can refer to arbitrary
devices.
Change-Id: Ifc8bd340e2e8859fe549f5724eb94269f587c418
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Make the API more similar to QtcProcess API.
Rename:
processStarted() -> started()
error() -> errorOccurred()
processError() -> error()
Change-Id: I86d650d55a643f5999fc91e56b985f699e2d7245
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Take the device from runnable passed in setRunnable().
If the intention is to run locally, set the device
to nullptr inside runnable. Otherwise we don't run locally.
Follows 47957de2dc
Change-Id: I5b381bb499cf76e469c844ac7474ce2f60761cef
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
And rename it to finished().
Maps better to what QtcProcess uses.
Change-Id: Ibfa018549f436b27638a791c0b4937c4459c9452
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
There's traditionally an odd duplication of the runnable.device
and the passed device here. Start disentangling things.
Change-Id: I1cc1628c99cea04d761fc4d8dd0cb232127ce055
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Use existing processStarted() signal instead.
Replace isRemoteRunning() with isLocal().
Change-Id: I58d0204888116c00e793fa43f969707013db06eb
Reviewed-by: hjk <hjk@qt.io>
Use existing appendMessage() for this purpose either with
StdErrFormat for remoteStderr() or with StdOutFormat for remoteStdout().
In case when device process is used in ApplicationLauncher
no appendMessage() was emitted so far with StdErrFormat or StdOutFormat.
Change-Id: I2f6603aaf28113fea2a8bb6bd1738320cc39be75
Reviewed-by: hjk <hjk@qt.io>
This is mimicking a bit what has been done on the baremetal side,
and is formally more correct when the gdbserver is not a real
gdbserver, but e.g. a probe speaking the gdb remote protocol.
Change-Id: I1b42624b94071b34c009bd0650095792a5b2fcb7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This unifies the remaining paths of RunWorker creation to always
use RunWorkerFactories in the plugin pimpls.
There were, and are, still effectively three basic kinds of workers:
- "toplevel" tools corresponding to the run modes, that are often all
that's used for local runs and directly started via the fat buttons
or e.g. entries in the analyze menu, with factories already previously
located in the plugin pimpls
- core "tool helpers", providing tool specific functionality typically
used in conjunction with a remote device specific run mechanism,
set up via RunControl::registerWorkerCreator
- target/device specific runhelper like port gatherers contructed e.g.
via *Device::workerCreator(Core::Id id)
Worse, these categories are partially overlapping, so it was not
clear how a "clean" setup would look like, instead some ad-hoc cobbling
"to make it work" happened.
In some cases, the runMode id was used throughout the whole ensemble
of run workers for a given run, and which worker exactly was created
depended on which of the mechanism above was used in which order.
With the new central setup, the top-level runmodes remain, but the
second kind gets new ids, so the implicit dependencies on order
of setup mechanism are avoided.
This also helps in the cases where there was previously unclarity of where
and how to set up worker factories: It's always and only the plugin
pimpl now.
Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is what the consuming code expects in most cases.
Change-Id: I135592039e28b994996186f627215ab1d2f8d6dc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
A plugin for communication with Boot2Qt devices.
Task-number: QTCREATORBUG-21808
Change-Id: I61f4a9451c2fe8ff4e1108e07db2e72e8c613c43
Reviewed-by: Kari Oikarinen <kari.oikarinen@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
