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>
The lines between engine setup and running have always been
blurry, so it looks more and more unnatural to enforce this
in the architecture. Remove the runEngine() call from the
end of notifySetupEngineOk, and do it on the user side.
Change-Id: I3a5e158e8b3fe9b0a288d064f798e24b2ac47f86
Reviewed-by: David Schulz <david.schulz@qt.io>
Calling first() or last() on temporary container may
unnecessarily detach the container. Fix it by calling
constFirst() and constLast().
Change-Id: I2460efd5dbee1534eec8a514d9bff2a947bfddf9
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This will be gone in Qt6 and seems unnecessary here as insertion
into the hash explicitly checks containment first, so this was
effectively not used as QMultiHash anyway.
Change-Id: I3f6ef9473930f72ee9b5f81f3623829d63619cc0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This triggered a soft assert in DebuggerEngine::showMessage()
and cleaning up the status bar is not necessary at all.
Change-Id: I12d3d5cbc79f178af58ecb0a5c7a3130c880bdad
Reviewed-by: hjk <hjk@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>
Avoid checking an invalid QUrl - instead restore
old code of always creating one an verifying this
instead.
Remove the now unused FilePath::isLocal().
Change-Id: I037c43e6fbdb7dc1f8901fc70b581f3c94ab503a
Reviewed-by: hjk <hjk@qt.io>
The reasoning in 1b4766e26c did not take into account that the scope
of QT_NO_JAVA_STYLE_ITERATORS may change over time, as done with
f70905448f6 in Qt base.
Change-Id: Ib1966ff26c4d36d5f62e149d6b45baa4aecf825d
Reviewed-by: Eike Ziller <eike.ziller@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>
This level is meant to take the role of current thread handler
in the long run, allowing per-thread stackviews in each engine.
For now, the additional level holds just a single, invisible
dummy item playing the role of a "current thread".
Change-Id: Ief6131500fc1aa8902f2313038a65840b80b495b
Reviewed-by: Christian Stenger <christian.stenger@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>
The engines are listed as virtual root items for their contents. This
way, when we need an engineID we can walk up the tree of watch items and
the last valid one will be the engine.
Fixes: QTCREATORBUG-21486
Change-Id: Ib110457dc65523c1e2b75aa073f6cd399bbc9532
Reviewed-by: hjk <hjk@qt.io>
Main menu action pass operation to current engine, everything else
is handled there.
Combine execute{Step,Next} and execute{Step,Next}I functions.
Implementation were mostly similar, in some cases unneeded
(the instruction-wise version e.g. for Python)
Drop GDB-isms 'step', 'next' in favor of 'step in' and 'step over'.
Change-Id: I232232bc7a67d9d297a74f1c81dc43be96787d34
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Otherwise we have a race condition. The breakpoints may be hit before
they are set.
Change-Id: Iccdd64758b150acdfadc18cba88abdf841feb6c7
Fixes: QTCREATORBUG-21253
Reviewed-by: hjk <hjk@qt.io>
Latest restructuring made the 'Add Expression Evaluator'
action to a no-op when not debugging.
Reflect this by disabling the action as long the user is
not debugging and allow complex expressions to be evaluated
for QML as well.
Fixes: QTCREATORBUG-19050
Change-Id: I2d6421a121e2169981b992a617f4d2b7264a8091
Reviewed-by: hjk <hjk@qt.io>
- Use the TreeItem/data pattern recently introduced with Breakpoints
to remove the need of keeping track of id/object mapping. Opens
possibility to have thread groups as intermediate level.
- Use the ThreadHandler directly as model for the thread combobox
to remove the need of manual combo box updates.
- Move setting current thread from individual engines to central code.
Change-Id: I030e21a4aa5ab30b0efbc84528d9cecf29cbbe30
Reviewed-by: David Schulz <david.schulz@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>
Newer versions of QML will support proper changing of break points, we
won't need to work around it anymore.
Task-number: QTCREATORBUG-20795
Change-Id: Idb5aaeb8ea59c7d2fd7c924e336ea259d3573d3d
Reviewed-by: hjk <hjk@qt.io>
As QML currently does not expose a command to atomically enable or
disable a breakpoint, we need to remove and re-insert it. The previous
code scheduled the removal through a timer, and depending on if the
timer hit before the insertion or after, the operation was successful or
not.
As the QML engine doesn't have to be in a specific state to insert and
remove breakpoints, we can just directly send the messages instead and
therefore be certain that they arrive in the right order.
Task-number: QTCREATORBUG-20795
Change-Id: If69797b2c75e1107ad552f88e709e1580b4164db
Reviewed-by: hjk <hjk@qt.io>
The debugger will treat any value you put in there as string, and then
fail to update the item because it doesn't expect the type to change.
Proper editing of JavaScript objects requires quite a bit more UI than
this, so disallow it for now.
Task-number: QTCREATORBUG-20736
Change-Id: I7bf6e7a3747cde3c6682b66aaa810291f753e85d
Reviewed-by: hjk <hjk@qt.io>
