...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
Now, QmlEngine creates the connection to the inferior (debuggee), and
notifies QmlInspector when a connection is established. Before,
inspector created the debugger engin, which was wrong.
QmlEngine's responsibilities are connecting to the debuggee and basic
QML/JS debugging features like locals & watchers, breakpoints etc.
QmlInspector takes care of Live Preview and other fancy inspection
features.
Reviewed-by: hjk
When a break point is hit, switch to the C++ debugger ui that
contains all the good widget for debugging.
This is a temporary fix, later the different engine should be
able to enable/disable part of the debugger ui as they whish
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).
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.
