I can't answer all your questions, as I'm not an expert on Qt's Model/View system, what I do know is,
that all models have a QAbstractItemModel as base model and that is also the ABI for all views.
For that reason alone, you can assign all models to all views. You will however not get a useful representation of all your data in all views.
As I understand it, and anyone fell me to correct me here, the other higher level classes of models are only there to make your life easier, as in you do not have to implement all functions/functionalities of the whole AbstractItemModel class
After thinking about this problem more and looking at the interface for QAbstractProxyModel, I am beginning to think that a subclass of a proxy model is not the answer. I am wondering if the best course of action would be to create a new model which keeps a pointer to my base model. Every time the various data changed signals are emitted from the base model, my "proxy" model determines if a new sequence has been found. It then keeps track of all the various sequences in its own internal data structure which keeps QPersistenModelIndex indexes into the base model. Then my "proxy's" data() method would use these indexes to get the real data from the underlying model but parsed into the correct format.
Do this sound like a better approach?
In this case, I am also wondering how to display my data as a table where each row could have a different number of columns. Perhaps I could keep track of the row with the maximum number of columns and return this in columnCount()? Then my data() method would just return QVariant() for columns that don't exist in a given row.
I'm doing something similar in sort of objects property tree. It works pretty well for large number of items. Definitely a massive win over a widget per item approach.
One difference to your approach is that I don't use grab(), but instead have the editors created by the delegate a static drawing function that uses QStyle::drawControl and friends to draw an image of itself. This is because I don't want to instantiate all the editor widgets upfront to grab them (I have a bunch of them and it takes time). It's sort of a trade-off because it can get out of sync with the actual widget look. Whether this is something you'd be interested in or not is up to you, but the general idea of drawing an image is a valid one.
Hi! Just to be sure I understood this correctly: You have a single DB with a humongous number of identically structured tables? Do you really believe you can store 2^128 bits / rows / tables / whatever in your database / filesystem / datacenter?
In worst case I will have to keep in RAM about 4e+38 of 16 bytes pointers
This makes it compile (even though I'm not sure about the implications), but it doesn't help me: there is no Show event handled in editorEvent ever (tested with printf-debugging - yes, before the test for QLineEdit), I'm only getting Mouse events.
Something like completer->popup()->show(); should do what you want.
Nope, does not help.
I figured (using qDebug, again), the place where I should put my popup-opening call is setEditorData. In there, I receive the QLineEdit and it's QCompleter: But I cannot make it show the popup. I tried now:
I think QAbstractItemModel and friends is a winner here. It contains a lot of optimized functions, that allow you to update single cells instead of invalidating the view, reconnecting the widgets, etc. It also allows you to leverage all the more advanced mechanisms like lazy initialization (canFetchMore() and fetchMore() methods).