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>
Mostly unused #include's, also sort them or reduce scope.
A few namespaces, ...
Change-Id: I9ee71e07de7157c9942125672addf87dd41e78f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
Most inclusions of idevice.h inside other headers are
required just because of IDevice::Ptr or IDevice::ConstPtr
was used there. Unfortunately, since these "using"
are defined inside a IDevice class, we just can't
forward declare IDevice::Ptr nor IDevice::ConstPtr.
Instead, create a separate header that defines
IDevicePtr and IDeviceConstPtr while having IDevice
forward declared. Redefine IDevice::Ptr/ConstPtr
inside IDevice to use IDevicePtr/IDeviceConstPtr.
Now, instead of forward declaring a IDevice::Ptr
it's sufficient to include the idevicefwd.h.
This drops the number of files being recompiled
after touching idevice.h from ~770 to ~210.
Change-Id: Ib6f2982aa0761fb4cd6593badb9c3c0c527ea535
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
The aspects are now responsible for defining what data needs
to be copied and also to provide a suitable interface (kind
of source-compatible to direct use) for access.
The important change here is that RunControl::aspect(...) doesn't
need to access RunControl::runConfiguration() in fully aspectified
RunConfigurations anymore. In not-fully aspectified the runConfig
access is moved to the user code to make the problem visible there.
Long term, aspectification should be finished.
As an additional benefit, the resolving of macros etc can
now be done at the correct time.
Change-Id: I690d9f8f696ce9b4efd42082ba3f81b514efcb77
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In favor of the FilePath/Link ones.
Change-Id: I5caf9e0f8de304ff4ee12329557aa50a6f3a0c69
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
Only four simple values.
Adapting qmlprofilerconfigwidget_test did not seem desirable,
as in the aspectified state this is hidden in the base aspects
implementations.
Change-Id: I933a8ca065169c61b7f25f109e0b7a0e6d21cb33
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There are very few reasons to use mainWindow() directly.
Especially for modal dialogs, using dialogParent() is important, since
that guarantees the stacking order in case of other dialogs currently
being open.
Change-Id: I7ad2c23c5034b43195eb35cfe405932a7ea003e6
Reviewed-by: hjk <hjk@qt.io>
This enforces a linear pass through
[static] ProjectExplorerPlugin::updateRunActions
ProjectExplorerPluginPrivate::doUpdateRunAction
[emit] ProjectExplorerPluginPrivate::runActionsUpdated
instead of the previous direct emission of the signal from
user code and connecting also the internal update to it.
This is meant to simplify reasoning about execution order and
maybe to help elimimating double executation.
Change-Id: Id8cc41a46d9dec06afb5514855f2ae80560f3695
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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 some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We need to do this in the remote connect case as the application itself
will not disconnect.
Fixes: QTCREATORBUG-22273
Change-Id: I1b343fd7d8658ce8d9aa5bf21b610940507d0dd4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... unless we actually triggered AppStopRequested. Furthermore, don't
clear the data in that case. The incomplete data could still be of some
value, and we call finalize() later on, which would otherwise confuse
the trace manager.
Fixes: QTCREATORBUG-22187
Change-Id: Ic4373201d6e9f29583186708a7acb6ba2ddcd502
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Into a trivial bit and two setters. Plan is to use it only with information
that is truly there (e.g. kit/device only) at the user side without having
to invent a RunConfiguration "handle".
Also remove some dead code in the test runner.
Change-Id: I987881e41722178b14b91f973b84cbdb67a9f85e
Reviewed-by: Christian Kandeler <christian.kandeler@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>
We need to set the "panelwidget" property for the foreground color to be
set. Now that we do this correctly we don't need to hack around in the
palette anymore in QmlProfiler.
Change-Id: Icdc737e1c74d16ec76a12dbbdf6f8f64062bd19c
Fixes: QTCREATORBUG-21961
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>
We don't need to waste the time and memory required to create the views
if they are never shown.
Change-Id: I56add08981c90263e6735f5b7e6fac2140b457e4
Fixes: QTCREATORBUG-21894
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@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>
Also, use QString uniformly for the (now rarely used) perspective ids.
Change-Id: I682062e7d179d0fcfd309e7714713bd1218bd8bb
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is a step towards properly supporting multiple debugger
sessions side-by-side.
The combined C++-and-QML engine has been removed, instead a
combined setup creates now two individual engines, under a single
DebuggerRunTool but mostly independent with no combined state
machine. This requires a few more clicks in some cases, but
makes it easier to direct e.g. interrupt requests to the
interesting engine.
Care has been taken to not change the UX of the single debugger
session use case if possible. The fat debug button operates
as-before in that case, i.e. switches to Interrupt if the
single active runconfiguration runs in the debugger etc.
Most views are made per-engine, running an engine creates
a new Perspective, which is destroyed when the run control dies.
The snapshot view remains global and becomes primary source
of information on a "current engine" that receives all menu
and otherwise global input.
There is a new global "Breakpoint Preset" view containing
all "static" breakpoint data. When an engine starts up it
"claims" breakpoint it believes it can handle, but operates
on a copy of the static data. The markers of the static
version are suppressed as long as an engine controls a
breakpoint (that inclusive all resolved locations), but are
re-instatet once the engine quits.
The old Breakpoint class that already contained this split
per-instance was split into a new Breakpoint and a
GlobalBreakpoint class, with a per-engine model for Breakpoints,
and a singleton model containing GlobalBreakpoints.
There is a new CppDebuggerEngine intermediate level serving as
base for C++ (or, rather, "compiled") binary debugging, i.e.
{Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine
base that are not applicable to non-binary debuggers.
Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This simplifies the toolbar setup and removes the need for the
stack of toolbar widgets.
The actions themselves have been owned by the plugin already,
so nothing changed in this respect.
Change-Id: I44754e16c8fc2acc53633dd9d560b1e732eece27
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
If you are retrying, then probably you want it to be more patient this
time. Also, tell the user how long we have waited and how long we are
going to wait when retrying.
In turn, reduce the number of "internal" retries. Retrying 10 times
should be enough to determine if the given timeout is too short. This
will give us an initial waiting time of 2s, and make the second try 4s.
Change-Id: Ibdfe02d041550eb16cadc59cec1b78ce97289b30
Task-number: QTCREATORBUG-20529
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
If the server stopped recording before breaking the connection, we're
fine.
Change-Id: Ic6d57cd4eb7c831cdd8aca1f305b44b9ecbd10dc
Task-number: QTCREATORBUG-20530
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This used to be important for the mockup in the Timeline, but as the
mockup looks just fine with all available features visible, we can drop
it. As TimelineModel::clear() clears the "hidden" flag, we have to
restore that one on initialize(), though.
As a side effect the visibility settings are retained across profiling
sessions now.
Task-number: QTCREATORBUG-20503
Change-Id: I1512ab7e494ed79d20e2097d68f8494990cfecbb
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The text marks are conceptually part of the type storage, not the event
storage. We need to hide them on initialize and show them again on
finalize, though, so that they get updated.
Task-number: QTCREATORBUG-20506
Change-Id: I5fe50110b99ea81b9a7585758a30fcad98bfcaa3
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This enables us to have multiple QmlProfilerTool instances without
conflicting action registrations. Ultimately there should be a way to
unregister actions, or to add some extra description on which tool
instance they refer to, but this is a minimal first step.
The main problem this fixes for now is the warnings generated by the
tests.
Change-Id: I2193fc48a5a68c52f46e5567919f3035bc93df36
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
We cannot have the model manager clear itself from the dtor, as the
order of deletion between the various other objects parented to the tool
is undefined. Make sure we get into a clean state before the model
manager disappears.
This fixes the soft asserts when the tests shut down.
Change-Id: I8fcd52a7c2d0703cbdd215d85aa1d80c2e3296a3
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>
This is redundant, now that we have registerFeatures().
Change-Id: Ia56c28b8892ab6da694570fe4b9ea5c96fe194f1
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This way we can use the trace file loading and saving mechanism for
other profilers.
Change-Id: I98ec1cdde6f7abcea152cabf72e64d4e696dfa59
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
