FWIW, this is a bit of workaround. Not having kcharselect crash for just about every search is well worth it though.
Also, I am not sure I particularly like the qtimer code. It does beat having to pass const char * method names to invokeMethod and turning the private into a qobject. With the lambda the resize call at least gets checked by the compiler ¯\_(ツ)_/¯

Reading your description on the referenced QTBUG, does it help to use a compare with previous m_columns in KCharSelectItemModel ::setColumnCount() before doing the emit dance?

In D6624#124077, @cfeck wrote:

Reading your description on the referenced QTBUG, does it help to use a compare with previous m_columns in KCharSelectItemModel ::setColumnCount() before doing the emit dance?

It probably does. To me, that would seem a bit too close to the cause though. If tomorrow another bit of the resizing calculation starts causing a re-layout it would crash again. That said, I think adding an if would be handy either way, what with saving a bunch of cpu cycles.

Considering that the Qt bug will not be fixed in the next few days (I hope to get around to it, but it's involved), this makes sense.

It probably does.

Were you able to test? I would prefer the simpler patch. I cannot test it, because my system does not have accessibility enabled.

In D6624#126465, @cfeck wrote:

It probably does.

Were you able to test? I would prefer the simpler patch. I cannot test it, because my system does not have accessibility enabled.

Yes, I did not manage to crash it that way.

As I said though, I do not think making the smallest possible fix is prudent here. While that change would be simpler it would also be more fragile. In resizeEvent() we'd still call a function of which the intention is to change the size of cells, which is meant to result in a layout change and thus potentially causes a resize, bringing us back to the crashing call chain. Making the column update conditional does fix the immediate cause of this right now. Conceptually the issue would still be there: we call a method of which the intention is to change the layout from within a resizeEvent handler. Something that is not safe to do with the current qaccessible lifetime management.
If someone goes ahead and changes the way the models are being used and/or when size calculation happens in the future we'll be crashing again.

TLDR I don't find introducing the if a future-proof solution. It's only treating the symptom. We'd reinforce a bone with a metal plate whilst ignoring the fact that the patient has a disorder that makes her run in front of cars.

(I do think that introducing that if would be handy eitherway, not as a measure of dealing with the crash though)

If you are sure that your fix is "correct", then please remove the comment. From reading it, it looks like a workaround for a Qt bug.

Reading your comment it is also wrong. Resizing the model does not cause a resize of the widget. The widget size is controlled by the layout manager.

In D6624#126503, @cfeck wrote:

If you are sure that your fix is "correct", then please remove the comment. From reading it, it looks like a workaround for a Qt bug.

It is a workaround. It crashes because the life time of the qaccessible objects is managed rather badly and fixing that is less trivial than this workaround.

Let's say someone fixes the referenced Qt bug, and we are at a point requiring that Qt version anyway. Are you going to remove the workaround?

In D6624#126506, @cfeck wrote:

Let's say someone fixes the referenced Qt bug, and we are at a point requiring that Qt version anyway. Are you going to remove the workaround?

Anyone who happens to stumble upon it can.