Crash while typing in search bar of KPageWidget with custom model

Development
1

hello, KDE community!

I have couple of questions regarding KPageWidgetModel / KPageWidget classes from KF6::KWidgetsAddons module.

Backstory: currently I’m developing an application to create and edit education robot move “scenarios”. These scenarios or protocols consist of some meta-information, device information and “steps” that robot should execute. Steps differ from each other with their own set of parameters, for example “sit” (position, speed), “sleep” (duration), etc. Pretty usual stuff.

I want to display this project in tree-view, kind of like projects are represented in CAD systems. So top-level tree elements would be “Project” and “Steps”, and they have to be persistent, regardless of protocol file user would load. Then, as second level tree elements, “Meta info” would be attached to “Project” and all steps would be attached to “Steps”. For each tree entry i would like to display relevant widget alongside to see/manipulate data inside model.

So i opted to use KPageWidgetModel first just to see how things work. I subclassed it with intent to store pointer to data model inside and add methods to manipulate data (add steps). In my model’s constructor i create and store couple of KPageWidgetItems for persistent entries.

Now, for trouble: i create KPageWidget, set model, open widget. When i enter something in search bar – everything crashes with SIGSEGV in qt_qFindChildren_helper function.

(note: got same issues with subclassing KPageModel, but i thought that i might have got overriden methods wrong or something, so temporarily swithed to KPageWidgetModel as simpler solution)

Here’s MWE that reproduces this error: https://gist.github.com/murych/20affb25438d48b27336a2fb9688235e (stacktrace included in first comment)

building environment:

  • Fedora 42,
  • gcc version 15.2.1 20260123,
  • qt 6.10.2,
  • kde frameworks 6.24.0

Am i doing something wrong? Is there any way to disable/hide search bar? Maybe using KPageWidgetModel (or, subsequently, KPageModel) is not good option for tree model that changes frequently?

2

so speaking about the crash itself, and not architecture questions: it’s pretty clear that the crash happens because KPageViewPrivate::onSearchTextChanged() iterates on KPageWidgetItem instances contained within the model, and one of those instances contains an unexpected nullptr where a QWidget should be.

If I had to guess as to why (i’m not familiar with KPageWidget), it’s probably because the pages are added with calls like addPage(nullptr, u"PROJECT"\_s), while in *KPageWidgetModel::addPage(QWidget *widget, const QString &name) you’re expected to have already created the widget you’re adding.

3

Why add a nullptr as page or subpage?

    explicit MyModel(Project *project, QObject *parent = nullptr)
        : KPageWidgetModel{parent}, _project{project},
        _hMeta{addPage(nullptr, u"PROJECT"_s)},
        _hProtocol{addPage(nullptr, u"PROTOCOL"_s)} {
        addSubPage(_hMeta, nullptr, u"meta info sub 1"_s);
        addSubPage(_hMeta, nullptr, u"meta info sub 2"_s);
    }
4

Thanks for helping!

I was under impression that adding nullptr as a widget is valid because KPageWidget has setDefaultWidget(QWidget*) method that is described as

Sets the \a widget which will be shown when a page is selected that has no own widget set

so you can add a null widget as long as the page item has a name.

Previously, I had the same issue filling a model with properly constructed widgets, so I thought that issue was not there.

Will try to fix this and report back with the results.

5

Thanks to you too!

As stated in a previous reply, I thought it was perfectly ok to add nullptr widgets to pages, because KPageWidget can show a placeholder widget if the page item has none.

That being said, I need to check if this would help. Will look into my implementation of KPageModel derived class as well, as its code is a bit more complex.

6

Ok, so my issue with KPageWidgetModel has been resolved by adding non-null widgets as pages. KPageWidget’s setDefaultWidget(..) method confused me, as it implies the model does not require an actual widget. But it definitely breaks text search in child classes.

Being used to managing the lifetime of heap objects with smart pointers rather than with Qt child-parent relations, explicitly tying page’s widget to model/parent widget felt unnecessary. That backfired too.

I will stick to using KPageWidgetModel instead of KPageModel for now, as it solves my problems + has simpler API and less reimplementation required.

I have some grudges, though. I do think that search bar should be optional (opt-out feature at very least). Didn’t see it in KF5 branch that I used in the past. I also believe that the text search should consider the scenario where KPageWidgetItem’s widget pointer is null.