breaks SOLID It doesn't. In fact, if it worked as you expected it would break SOLID it's definitely a serious design flaw Sorry to be brutal: No, it's not a flaw, you just didn't understand the design of model/views. To help you get a better idea of what is going on, try use the same model with 2 different treeviews. In only one of the view call setRootIndex, and then trigger the filtering.

@IMAN4K said in change QSortFilterProxyModel behaviour for multiple column filtering: Answer from stackfverflow : http://stackoverflow.com/questions/39488901/change-qsortfilterproxymodel-behaviour-for-multiple-column-filtering This answer is the typical example that lead people to say subclassing QSortFilterProxyModel, which would likely have a very limited reusability It's bad. the proxy model implementation should not depend on the structure of the underlying data in sourceModel

Adapted from the documentation example: model->setFilter("should_alarm=1");

You could stack two QSortFilterProxyModels on top of the each other, one filtering on the first column/value, and the other on the second column/value. Alternatively, you could subclass QSortFilterProxyModel to override filterAcceptsRow() and compare two columns against two filter values (the first is the existing column and value, and a second you add)