To clear things up a little, C::B doesn't even know/care if a debugger plugin is loaded. If you want to create 10 debugger plugins, C::B will load them happily. If you want to make them share menus between them or each to his own, that's up to you.
Thanks mandrav. This is the kind of insight that is very useful. I would hate to see the crazy mess that would result with 10 debugger plugins floating around.
Is there a case for defining a project specific debugger so when a specific project is active so is the particular debugger? When a user switches projects with a new debugger CB could request that the debugger hide/release some/all of its UI, so it can be replaced with the UI of the alternate debugger. I guess this hasn't been an issue to date because the only current alternate debugger, CDB, is handled within GDBdebugger.
3. C::B passes UI messages to all plugins.
to test this i added a quick message box to report AddBreakpoint events hitting my plugin:
virtual bool AddBreakpoint(const wxString& file, int line) {wxMessageBox(_T("Python Breakpoint!")); return true;}
unfortunately, these only seemed to make it when GDBdebugger was turned off. Does this mean:
A) CB passes messages to debuggers until the first true is returned?
B) CB passes messages only to the first debugger?
probably the former. if so, should GDBdebugger only be allowing breakpoints for its known filetypes or should the messaging be changed to send to all plugins regardless? probably better to send to all plugins (or the "active" plugin)
AFAIR, the only place in the sdk where a debugger plugin is checked for existence, is in the editor code to notify the debugger about setting/unsetting breakpoints.
with all the "virtuals" i wasn't sure which ones would get called by the framework.