Well, yes, when displaying huge databases, for example. This use-case pops up quite often from my experience. It is rare to contain more than 2^31 elements, yes, but one has to be aware of that case and support it somehow which leads to overcompicated code that does «paging», for example. And paging splits the data which is poor UX too. Of course, to make it usable, you have to add filters on top of that, but you’d probably need them anyway while paging is just an overcomplicating with no gain. Note that the model might not contain the data but retrieve it upon request from the view, e.g. store some cache. An example of such a huge model can be the hex model that displays the contents of the file. Normally, files are not that big, but they are theoretically possible. Of course, one can say that «nobody needs» it, that this is corner use-case… Well, libraries have to support corner use-cases, haven’t they?
Ivan > 25 авг. 2020 г., в 01:09, Thiago Macieira <thiago.macie...@intel.com> > написал(а): > > On Monday, 24 August 2020 15:10:24 PDT Иван Комиссаров wrote: >> It would be nice if QAbstractItemModel will support qsizetype instead of >> int, but I do not see how this is possible considering the fact that >> rowCount/columnCount return int. I suppose, it is not very hard to patch >> QModelIndex, but what to do with virtual functions? The user code will >> break. The only solution I see is to add QAbstractItemModelV2 with the >> «wide» interface and provide a proxy for the old one. > > Do we need models with more than 2 billion rows or columns? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
