GitLab

This mainly allows for more precise shutdown and tightens the set
of allowed transitions.

If a plugin requests asyncronous shutdown, the shutdown sequence does
not continue to deleting the plugins before it has sent a
asynchronousShutdownFinished signal. During that time an event loop
is running.

This updates the state diagram in debuggerplugin.cpp and
renames AdapterStart{Fail}ed to EngineStart{Fail}ed.

(that have no other standard)

Reviewed-by: dt

Task-number: QTCREATORBUG-598

Added adapter to work with TCF over WLAN.
Factor out common code for Symbian from TrkAdapter.
Improve message logging in TrkGdbAdapter, some cleanup.
Added new TcfTrkGdbAdapter based on TcfTrkDevice
in symbianutils based on JSON, using QTcpSocket.
To be started via special @tcf@ argument.
Rubber-stamped-by: hjk

A mostly mechanical change.

Reviewed-By: con

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.