Extension to QSortFilterProxyModel
-
But if you want to do that in a specialized proxy modelm, you would have to reimplement nearly complete QSortFilterProxyModel, as you need the filtering for that. and the the model also needs to be sorted, you need the full funtionality. And thats a lot of code. If you only do that for one specific source model it's easy, but we need it for different types of source models...
The specialozed proxy you are talking about would be nearly the same as QSotrtFilterProxyModel, except it can add some rows in the top... -
hm, why number two and number three are identical? Typo? As I understood number two should be about columns.
-
[quote author="Gerolf Reinwardt" date="1290864507"]Hi,
sorry you are right, number 2 should be columns :-) But how can I change the text of a poll?[/quote]
Done.
-
I don't see any other solution except writing your own specialized proxy model. A generic proxy model within Qt libs should have expectable behavior. One of this is that each and every data you get out of the proxy model is contained in the source model. If you had rows only existing in the proxy model but not in the source model, this would break expectable behavior. And, what should "QAbstractProxyModel::mapToSource()":http://doc.trolltech.com/4.7-snapshot/qabstractproxymodel.html#mapToSource return in this case?
Regarding the coding effort: You can grab the sources of QSortFilterProxyModel and modify it for your needs. As long as you just copy and modify it and it works for you (using the index mappings etc.), you need not worry about the Trolls changing the implementation in future versions of Qt because you have all the code in your own files. Althogh a short diff on the two versions might be a good idea, just in case the trolls fixed some bugs :-)
-
Hi,
I already did that, and it works. But why not have such a sollution in the base? Perhaps a second proxy for such things. And map to source must of course retunr an invalid model index. But I saw also other, who wanted such features. if it is part od QSortFilterProxyModel or part of a second model, does not matter. And addin additional stuff by a proxy (for grouping, auto filters or whatever) is not that bad as an idea I think.The interesting thing is, do we want another base class or not. Why not add the possibility, to add rows and columns in the front, to be able to implement such features. The auto filtzering should not be part of the Qt implementation, but the prerequisites could be there. If some people don't need this feature, they needn't switch it on :-)
-
IMHO it breaks the contract that was made in QAbstractProxyModel (returning an invalid QModelIndex in the context of the source model for a valid index in the proxa model) and is therefore not subject for a public API resp. the Qt libs. This might be better placed in a Qt solutions site.
-
As far as I am aware the whole model view framework is meant to cover what 90% of the people need and to allow for everything the other 10% want to do.
I am not sure that it is a good idea to add functionality that is really important if you want to write a spreadsheet... it just adds lots of functionality that all the people who just need to display some data in a table will never need.
Please note that more advanced table views are available... including some that try hard to behave like excel. Just google:-)
-
I don't see a role for this in QSFPM at all. If you want to add filtering capabilities in a top row, why not subclass QHeaderView instead? In my opinion, that would be a logical place to put such a thing.
I am not saying that there is no place for a proxy model implementation that can merge data from more than one data source, but QSFPM is not it IMHO.
-
Closed after authors request.