KDevelop Checker Framework – pushed

Hi there!

I’m pleased to announce that the KDevelop Checker Framework has been pushed to the KDevPlatform repository. Here are some details about it:

GUI changes

• Moved ProblemModel to shell
• Reworked the Problems toolview. Now it works like this:
  • ProblemModels are added to ProblemModelSet.
  • ProblemReporterFactory makes instances of ProblemsView.
  • ProblemsView takes the models from ProblemModelSet (also subscribes for updates about them, so if one is added or removed it can add/remove their views) and it provides a tabbed widget where the views for them can be added. It creates instances of ProblemTreeView which show the problems in ProblemModel, and adds them to the tabs. Also the tabs shows the number of problems in the ProblemModels.
  • The toolview will only add actions that are supported by the model (for example: filtering, grouping, reparsing, showing imports. Obviously reparsing doesn’t make sense for runtime problem checkers)

See the video:

• First it shows that the “old” problem reporter still works as intended (which also uses the new code now)
• Then from 1:07 onward it shows an example problem model/view working with randomly generated test data.
• It shows the features of the new model(s), that is filtering by files/project and issue severity.
• It also shows the grouping support (grouping by severity, and path.

ProblemModel details

• Broke up ProblemModel into 2 parts
  • Base ProblemModel that provides the QAbstractItemModel interface for views and can use various ProblemStores to store problems. By default it uses FilteredProblemStore.
  • ProblemReporterModel is basically the old ProblemModel that grabs problems from DUChain, it’s a subclass of ProblemModel.
• ProblemStore simply stores problems as a list (well technically it stores them in a tree, but it only has 1 level, so it’s a list). There’s no filtering, no grouping. It’s perfect for ProblemReporterModel since it does filtering itself when grabbing the problems from DUChain.
• FilteredProblemStore DOES filtering, and grouping itself. It stores problems in a tree (ProblemStoreNode subclasses). The tree structure depends on the grouping method, which is implemented with GroupingStrategy subclasses.
• Moved WatchedDocumentSet and it’s subclasses from ProblemModel to ProblemStore, as it is really a detail that the model itself doesn’t need, however ProblemStore which stores the problems needs it actually.
• Created a new Problem class, DetectedProblem and moved both this and the “old” Problem class in under the IProblem interface. The intent here was to create a class with a clear interface for problems, which ProblemStore can simply store. I wanted to eventually clear the problems out of DUChain and replace the “old” Problem class with it. However I realized that it’s not practical because of the “show imports” feature which shows the problems from imported contexts. Unfortunately DUChain is the class that knows those, and it’s way too much work to get it out from it. Not to mention it doesn’t even make sense, since it’s really something that logically belongs there.

Using this new system is fairly straightforward:

All one has to do is instantiate a model, add it to the model set:

KDevelop::ILanguageController *lc =  KDevelop::ICore::self()->languageController();
KDevelop::ProblemModelSet *pms = lc->problemModelSet();
m_model = new KDevelop::ProblemModel(this);
pms->addModel(“Test”, m_model);

Then later inject problems into it:

KDevelop::DetectedProblem *p = new KDevelop::DetectedProblem();
p->setDescription(“Some message”);
p->setFinalLocation(KDevelop::IndexedString(“/just/a/bogus/path/yada.cpp”));
p->setSource(KDevelop::IProblem::Plugin);
p->setSeverity(KDevelop::IProblem::Error);
model->addProblem(KDevelop::IProblem::Ptr(p));

Here’s a class diagram about the relevant classes: