GitLab

Use virtual function instead of if/qobject_cast cascades.

There's  some 'external' and some 'internal' part now. Other plugins
are only supposed the external interface.

Check whether the ports we need are actually available on the device.
As a side effect, this makes it possible to debug more than one
application at the same time on Maemo.

Task-number: QTCREATORBUG-2702

Pass on error message when engine creation fails.

Reviewed-by: hjk
Task-number: QTCREATORBUG-2608

Reviewed-by: dt

Reviewed-by: kh1

namespace (from Debugger::Internal) as they are exported classes.
Introduce private classes to avoid exposing private JS debugger
headers.

Reviewed-by: hjk
Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>

Reviewed-by: hjk

A new debugger engine, QmlCppEngine, is introduced, which wraps gdb
and qml engines into one. Alternatively, if using Windows, Cdb is used
instead of Gdb.

Most of the debugger ui switcher is now rewritten, and it is tailored
for the QML and CPP layout case, the only one supported anyway.

Reviewed-by: hjk

...which subclasses DebuggerRunner and does not call
DebuggerPlugin::startDebugger(), which connects the
engine, leading to strange malfunctions. Move functionality
to DebuggerRunner::start() to make it self-contained.
Add object names to engines for easier debugging.

Reviewed-by: hjk

As it created 2 output panes that could be closed indepently
of each other.

Fix breakage introduced by the new asynchronous stop() methods
of the debugger run controls. Allow for RunControl::stop() to
be asynchronous by introducing a return enumeration indicating
that. Introduce additional method aboutToStop() asking user
to quit (tie that to the RunControl instead of having to hack
the behaviour elsewhere).
If asynchronous stop is detected, terminate the ProjectExplorer
asynchronously.
This makes the behaviour consistent across switching sessions/
closing outputwindow tabs and quitting Qt Creator.

Reviewed-by: dt
Rubber-stamped-by: hjk

We'd like to be able to restart a debugger engine at some point of time.

This replaces the (de facto) singleton engines and data handlers by classes
that are instantiated per run. The DebuggerRunControl will now create an
object of (a class derived from) DebuggerEngine that contains all the relevant
"dynamic" data.

DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin,
whereas the data bits went to DebuggerEngine.

There is no formal notion of a "current" DebuggerEngine. However, as there's
only one DebuggerEngine at a time that has its data models connected to the
view, there's still some "de facto" notion of a "current" engine. Calling
SomeModel::setData(int role, QVariant data) with custom role is used as the
primary dispatch mechanism from the views to the "current" data models
(and the engine, as all data models know their engine).

Plan is to move the models themselves from DebuggerManager to
DebuggerRunControl.

Pass output through the RunControl instead of the DebuggerManager.

This replaces most uses of DebuggerStartParameters by DebuggerRunControl
which is a simple RunControl with a DebuggerStartParameters member.

Plan is to move all global state to the run controls, and possibly
introduce specialized ones for core debugging etc.