| 205 | } |
| 206 | |
| 207 | MIDebugSession* MIDebuggerPlugin::createSession() |
| 208 | { |
| 209 | auto* const debugController = core()->debugController(); |
| 210 | auto* const session = createSessionObject(); |
| 211 | |
| 212 | // Our tool views are registered only while a debug session created by this plugin is the current session of |
| 213 | // DebugController. This way, for example, only LLDB (and not GDB) tool views are present during an LLDB session. |
| 214 | |
| 215 | auto toolViewFactoryHolder = reuseOrCreateToolViewFactoryHolder(debugController->currentSession()); |
| 216 | |
| 217 | // Register the tool views *before* adding the new session to the DebugController. Otherwise, |
| 218 | // the tool views are registered after the Debug sublime area becomes active, which usually |
| 219 | // resets custom tool view positions to the default ones and never restores tool view visibility. |
| 220 | // Once these tool view issues are fixed in Sublime, consider reordering the next |
| 221 | // two statements to optimize (the tool view widgets would not have to set up the UI |
| 222 | // for a null current session before adapting it for the just created session). |
| 223 | session->initializeToolViewFactoryHolder(std::move(toolViewFactoryHolder)); |
| 224 | debugController->addSession(session); |
| 225 | |
| 226 | connect(session, &MIDebugSession::showMessage, this, &MIDebuggerPlugin::showStatusMessage); |
| 227 | connect(session, &MIDebugSession::raiseDebuggerConsoleViews, this, &MIDebuggerPlugin::raiseDebuggerConsoleViews); |
| 228 | return session; |
| 229 | } |
| 230 | |
| 231 | void MIDebuggerPlugin::slotExamineCore() |
| 232 | { |
no test coverage detected