[Debugger] Allow message to invoke Debugger and debug an app from Roster Launch

[adamfowleruk]

As per the issues on Paladin here: ​https://github.com/HaikuArchives/Paladin/issues/113

Would be nice if Debugger::MessageReceived could be passed a reference to a built app to debug, the location of the source files to show if a problem is found, and any other relevant configuration.

As an extension, Please consider receiving a message callback (somehow...) so Debugger can pass basic state information (running, crashed, quitting) etc. back to Paladin (or any other app) for status updates.

Not sure how this would interact with the 'Teams' model. Perhaps just create a team on the fly?

[anevilyak]

This is already possible by passing the path to the team via argc/argv in BRoster::Launch(). That being said, as far as properly integrating Paladin with it goes, the debugger core is separated out into a library (libdebugger.so), so in the long term the ideal approach would be for Paladin to hook into that directly. This would allow it to fully control launching, stepping, etc. directly as a true IDE rather than loading the debugger as an external app. The lib API is not yet considered entirely stable though, so its headers aren't yet published.

[adamfowleruk]

Yeah I can confirm using argc/argv does indeed launch it separately. I'll bake that in to Paladin for now, and log an issue to look at debugger choice and invocation at a later date.

I'd still like to see status monitoring hooks to the debugger app. Perhaps embedding a Debugger View inside Paladin would be better than using the lower level library and rolling my own. At least there's some consistency there then?

[anevilyak]

With all due respect, that's not a direction I'd like to go in. Being able to integrate with other apps is exactly what the core library is for, and it already provides all the events that something like Paladin would need. The Debugger application itself is intended to simply be a baseline provided with the OS when nothing else is available, and the needs for that are somewhat different from what a more advanced IDE would want to provide. I really don't want the app to be a dependency of a third party, since that starts putting design and implementation constraints on the entire UI out of concern of breaking compatibility, not just the core library.