WIP: Open from cache / Open Normally
Needs ReviewPublic

Authored by tcanabrava on Jul 13 2019, 5:44 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

DrKonqi is a strange beast:

Everything goes thru the static initializers in drkonqi.h, followed by a drkonqi::init()
then every other class in the project assumes that this happened to fetch values. this brings problems in many areas:
I can't create a DrKonqiDialog passing arguments, the arguments are supposed to be precalculated in the static methods of the DrKonqi superclass (that behaves more like a namespace than a Class). I can't easily create a Upload thru bugzilla too - it assumes that the app is running.

This is a trial - that doesn't work - on what I'm trying to do. This one is a failed attempt.

To do this correctly I would need to redo the main architecture of DrKonqi. This is a start of that idea.

Diff Detail

Repository
R871 DrKonqi
Branch
restoreWithGui
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 13913
Build 13931: arc lint + arc unit
tcanabrava created this revision.Jul 13 2019, 5:44 PM
Restricted Application added a project: Plasma. · View Herald TranscriptJul 13 2019, 5:44 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
tcanabrava requested review of this revision.Jul 13 2019, 5:44 PM
tcanabrava edited the summary of this revision. (Show Details)Jul 13 2019, 5:48 PM
sitter added a subscriber: sitter.Jul 15 2019, 1:40 PM

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).