feedc0de/qt-creator
1
0
Fork 0
forked from qt-creator/qt-creator
Code Pull Requests Activity
Files
0e318bfcf5244dde62e8afa46bd90d68bdaa0534
qt-creator/src/plugins/debugger/threadshandler.cpp

287 lines
8.3 KiB
C++
Raw Normal View History

debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
/**************************************************************************
**
** This file is part of Qt Creator
**
** Copyright (c) 2010 Nokia Corporation and/or its subsidiary(-ies).
**
** Contact: Nokia Corporation (qt-info@nokia.com)
**
** Commercial Usage
**
** Licensees holding valid Qt Commercial licenses may use this file in
** accordance with the Qt Commercial License Agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and Nokia.
**
** GNU Lesser General Public License Usage
**
** Alternatively, this file may be used under the terms of the GNU Lesser
** General Public License version 2.1 as published by the Free Software
** Foundation and appearing in the file LICENSE.LGPL included in the
** packaging of this file. Please review the following information to
** ensure the GNU Lesser General Public License version 2.1 requirements
** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
**
** If you are unsure which license is appropriate for your use, please
** contact the sales department at http://qt.nokia.com/contact.
**
**************************************************************************/
#include "threadshandler.h"
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
#include "debuggerconstants.h"
#include "debuggerengine.h"
debugger: fix display of correct thread in the thread combobox
2010-07-21 13:11:03 +02:00
#include <QtCore/QDebug>
Debugger: Make threads tooltip more verbose CDB: Add more information and state to Thread. Refactor thread information in CdbCore classes to prepare for more information.
2010-07-02 14:35:41 +02:00
#include <QtCore/QTextStream>
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
namespace Debugger {
namespace Internal {
////////////////////////////////////////////////////////////////////////
//
// ThreadsHandler
//
///////////////////////////////////////////////////////////////////////
ThreadData::ThreadData(int threadId)
{
notifyRunning();
id = threadId;
}
void ThreadData::notifyRunning()
{
address = 0;
function.clear();
fileName.clear();
frameLevel = -1;
state.clear();
lineNumber = -1;
}
Debugger: Make threads tooltip more verbose CDB: Add more information and state to Thread. Refactor thread information in CdbCore classes to prepare for more information.
2010-07-02 14:35:41 +02:00
static inline QString threadToolTip(const ThreadData &thread)
{
const char tableRowStartC[] = "<tr><td>";
const char tableRowSeparatorC[] = "</td><td>";
const char tableRowEndC[] = "</td>";
QString rc;
QTextStream str(&rc);
str << "<html><head/><body><table>"
<< tableRowStartC << ThreadsHandler::tr("Thread&nbsp;id:")
<< tableRowSeparatorC << thread.id << tableRowEndC;
if (!thread.targetId.isEmpty())
str << tableRowStartC << ThreadsHandler::tr("Target&nbsp;id:")
<< tableRowSeparatorC << thread.targetId << tableRowEndC;
Debugger[CDB]: Add thread names.
2010-09-17 13:28:50 +02:00
if (!thread.name.isEmpty())
str << tableRowStartC << ThreadsHandler::tr("Name:")
<< tableRowSeparatorC << thread.name << tableRowEndC;
Debugger: Make threads tooltip more verbose CDB: Add more information and state to Thread. Refactor thread information in CdbCore classes to prepare for more information.
2010-07-02 14:35:41 +02:00
if (!thread.state.isEmpty())
str << tableRowStartC << ThreadsHandler::tr("State:")
<< tableRowSeparatorC << thread.state << tableRowEndC;
if (!thread.core.isEmpty())
str << tableRowStartC << ThreadsHandler::tr("Core:")
<< tableRowSeparatorC << thread.core << tableRowEndC;
debugger: fix display of correct thread in the thread combobox
2010-07-21 13:11:03 +02:00
if (thread.address) {
Debugger: Make threads tooltip more verbose CDB: Add more information and state to Thread. Refactor thread information in CdbCore classes to prepare for more information.
2010-07-02 14:35:41 +02:00
str << tableRowStartC << ThreadsHandler::tr("Stopped&nbsp;at:")
<< tableRowSeparatorC;
if (!thread.function.isEmpty())
str << thread.function << "<br>";
if (!thread.fileName.isEmpty())
str << thread.fileName << ':' << thread.lineNumber << "<br>";
str.setIntegerBase(16);
str << "0x" << thread.address;
str.setIntegerBase(10);
}
str << "</table></body></html>";
return rc;
}
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
////////////////////////////////////////////////////////////////////////
//
// ThreadsHandler
//
///////////////////////////////////////////////////////////////////////
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
ThreadsHandler::ThreadsHandler(DebuggerEngine *engine)
: m_engine(engine),
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
m_currentIndex(0),
m_positionIcon(QLatin1String(":/debugger/images/location_16.png")),
m_emptyIcon(QLatin1String(":/debugger/images/debugger_empty_14.png"))
{
}
int ThreadsHandler::rowCount(const QModelIndex &parent) const
{
// Since the stack is not a tree, row count is 0 for any valid parent
return parent.isValid() ? 0 : m_threads.size();
}
int ThreadsHandler::columnCount(const QModelIndex &parent) const
{
return parent.isValid() ? 0 : int(ThreadData::ColumnCount);
}
QVariant ThreadsHandler::data(const QModelIndex &index, int role) const
{
if (!index.isValid())
return QVariant();
const int row = index.row();
if (row >= m_threads.size())
return QVariant();
const ThreadData &thread = m_threads.at(row);
Debugger: Make threads tooltip more verbose CDB: Add more information and state to Thread. Refactor thread information in CdbCore classes to prepare for more information.
2010-07-02 14:35:41 +02:00
switch (role) {
case Qt::DisplayRole:
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
switch (index.column()) {
case ThreadData::IdColumn:
return thread.id;
case ThreadData::FunctionColumn:
return thread.function;
case ThreadData::FileColumn:
return thread.fileName;
case ThreadData::LineColumn:
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
return thread.lineNumber >= 0
? QString::number(thread.lineNumber) : QString();
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
case ThreadData::AddressColumn:
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
return thread.address > 0
? QLatin1String("0x") + QString::number(thread.address, 16)
: QString();
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
case ThreadData::CoreColumn:
return thread.core;
case ThreadData::StateColumn:
return thread.state;
Display thread names extract thread names from QThread object name Task-Number: QTCREATORBUG-382 Reviewed-by: hjk
2010-09-13 12:37:30 +02:00
case ThreadData::NameColumn:
if (thread.name.isEmpty())
return thread.id;
return thread.name;
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
}
Debugger: Make threads tooltip more verbose CDB: Add more information and state to Thread. Refactor thread information in CdbCore classes to prepare for more information.
2010-07-02 14:35:41 +02:00
case Qt::ToolTipRole:
return threadToolTip(thread);
debugger: fix display of correct thread in the thread combobox
2010-07-21 13:11:03 +02:00
case Qt::DecorationRole:
// Return icon that indicates whether this is the active stack frame
Debugger: Make threads tooltip more verbose CDB: Add more information and state to Thread. Refactor thread information in CdbCore classes to prepare for more information.
2010-07-02 14:35:41 +02:00
if (index.column() == 0)
return (index.row() == m_currentIndex) ? m_positionIcon : m_emptyIcon;
break;
default:
break;
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
}
return QVariant();
}
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
QVariant ThreadsHandler::headerData
(int section, Qt::Orientation orientation, int role) const
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
{
if (orientation != Qt::Horizontal || role != Qt::DisplayRole)
return QVariant();
switch (section) {
case ThreadData::IdColumn:
return tr("Thread ID");
case ThreadData::FunctionColumn:
return tr("Function");
case ThreadData::FileColumn:
return tr("File");
case ThreadData::LineColumn:
return tr("Line");
case ThreadData::AddressColumn:
return tr("Address");
case ThreadData::CoreColumn:
return tr("Core");
case ThreadData::StateColumn:
return tr("State");
Display thread names extract thread names from QThread object name Task-Number: QTCREATORBUG-382 Reviewed-by: hjk
2010-09-13 12:37:30 +02:00
case ThreadData::NameColumn:
return tr("Name");
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
}
return QVariant();
}
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
bool ThreadsHandler::setData
(const QModelIndex &index, const QVariant &value, int role)
{
if (role == RequestSelectThreadRole) {
m_engine->selectThread(value.toInt());
return true;
}
return QAbstractTableModel::setData(index, value, role);
}
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
int ThreadsHandler::currentThreadId() const
{
if (m_currentIndex < 0 || m_currentIndex >= m_threads.size())
return -1;
return m_threads[m_currentIndex].id;
}
void ThreadsHandler::setCurrentThread(int index)
{
if (index == m_currentIndex)
return;
// Emit changed for previous frame
QModelIndex i = ThreadsHandler::index(m_currentIndex, 0);
emit dataChanged(i, i);
m_currentIndex = index;
// Emit changed for new frame
i = ThreadsHandler::index(m_currentIndex, 0);
emit dataChanged(i, i);
}
Debugger: Show current thread correctly in reply to thread-info. Reviewed-by: hjk
2010-07-02 10:58:47 +02:00
void ThreadsHandler::setCurrentThreadId(int id)
{
const int index = indexOf(id);
if (index != -1) {
setCurrentThread(index);
} else {
qWarning("ThreadsHandler::setCurrentThreadId: No such thread %d.", id);
}
}
int ThreadsHandler::indexOf(int threadId) const
{
const int count = m_threads.size();
for(int i = 0; i < count; i++)
if (m_threads.at(i).id == threadId)
return i;
return -1;
}
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
void ThreadsHandler::setThreads(const Threads &threads)
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
{
m_threads = threads;
if (m_currentIndex >= m_threads.size())
debugger: fix display of correct thread in the thread combobox
2010-07-21 13:11:03 +02:00
m_currentIndex = -1;
layoutChanged();
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
}
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
Threads ThreadsHandler::threads() const
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
{
return m_threads;
}
void ThreadsHandler::removeAll()
{
m_threads.clear();
m_currentIndex = 0;
debugger: fix display of correct thread in the thread combobox
2010-07-21 13:11:03 +02:00
layoutChanged();
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
}
void ThreadsHandler::notifyRunning()
{
// Threads stopped (that is, address != 0 showing)?
if (m_threads.empty())
return;
if (m_threads.front().address == 0)
return;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
const Threads::iterator end = m_threads.end();
for (Threads::iterator it = m_threads.begin(); it != end; ++it)
debugger: refactor thread related class
2010-05-18 12:12:22 +02:00
it->notifyRunning();
emit dataChanged(index(0, 1),
index(m_threads.size() - 1, ThreadData::ColumnCount - 1));
}
} // namespace Internal
} // namespace Debugger
Copy Permalink