sitter added a comment.
I would break the problem apart: pretend you only have one cached report. By wanting to deal with multiple reports at once I imagine you are making this more complicated than it is. With a single report you have two discrete input source options: live and cached. They represent the exactly same thing with (ideally) complete values for everything (name,exe,pid...) so all you need to do is rejigger the backend classes so they read the relevant information. The way I imagine this should work is in main() you branch depending on whether drkonqi is loading cached or live info, factorize the information (i.e. set it in DrKonqi) and construct a debugger (derive gdbdebugger and make it load data from in-memory for cached) + parser, then everything should technically work. Once you can report a single cached report it needs to be made to scale.... For multiple cached reports I think it's entirely feasible to then simply have your CacheWidget dialog be a separate process that forks a drkonqi process for each report that needs filing. Each drkonqi process is then still only responsible for a single report and all previously made assumptions about how there is only one crashed application etc. continue to hold true. From there we can still refactor to make the classes not rely on singletons and allow multiple reports to exist within the same process (if necessary at all, it may make no UX difference in the end). REPOSITORY R871 DrKonqi REVISION DETAIL https://phabricator.kde.org/D22445 To: tcanabrava Cc: sitter, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
