[Qt-interest] [SOLVED] Responding to when a QSortFilterProxyModel is initialized

[Jeffrey Brendecke]

> Jeffrey Brendecke wrote:
> > Thanks for the response!
> >
> > This got me going in the right direction:
> >> const QModelIndex firstItem = view->model()->index(0, 0);
> >
> > I had overlooked that it was that simple to get the first item in the
> > proxy model that way.
> >
> > The rest was setting up signals and slots so that after the model was
> > refreshed:
> > * Refreshing the model sent a notification to this effect to the view.
> > * The model then notified the view to make a request for the resource via
> > a signal.
> > * The view responded, mapped the proxiedRowNo at zero to the sourceRowNo
> > and sent a request to the sourceModel for the currentRowNo via a signal.
> > * After the resources were ready, the model notified the view via a
> > signal that the resources had been retrieved and were ready.
> > * The view sent a signal to the editor to load the resources from the
> > model.
>
> This seems over complicated. But at the same time if it works it works.
>
> Some pointers:
>
> You say you are emitting a signal (presumably after reset). Is that a
> custom signal? From a purity point of view it doesn't make sense to add
> signal api to the model. It makes it hard to add more proxies later and
> breaks encapsulation.
>
> After that the model is signalled to get a resource. Is that via a public
> slot? (also breaks encapsulation) It is usually best to communicate with
> the model like that through the data() method with a custom role. That will
> automatically be mapped to source so the view doesn't need particular
> knowledge that it is working with a proxy and that under that there is a
> model of a particular type. It just uses the QAbstractItemModel api.
>
> Next the model notifies the view that a resource is ready. Is that a custom
> signal? That's what dataChanged is for.
>
> The last point about the editor looks like you should maybe just be calling
> QAbstractItemView::edit(QModelIndex). That will query the model for the
> data for the Qt::EditRole (through any proxies automatically) and create a
> delegate using a factory containing the data. You can even make the model
> lazily fetch the resource when editrole is called and emit dataChanged when
> it is ready. I think the delegate will update in that case.
>
> > Changing the selection was a little different in that it sent the signal
> > to the model mentioned above to get the resource at the current
> > sourceRowNo.
>
> You can also have edit() auto-triggered when a selection is made I think.
>
> Just some stuff for you to look in to.
>
> All the best,
>
> Steve.
>
> > The editor could then respond rather ignorantly to notifications of
> > resource availability.
> >
> > Sincerely,
> >
> > Jeffrey Brendecke
> >
> > Managing Director
> > icanetix Software Systems and Consulting GmbH
> > Untere Hagenstrasse 26
> > 91217 Hersbruck
> > Germany
> >
> > Commercial Registry B 25317 Nuremberg, Germany
> > VAT-ID: DE250213502
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest

------------

I appreciate the time very much that you put into your response. These look 
like very helpful suggestions that would definitely clean up and simplify the 
design not to mention making it easier to make more use of the model in other 
contexts.

I think I got stuck on the model access methods (data() and so on) being tied 
to the table of information describing (but not directly containing) the 
resources and had totally forgotten about custom roles. I can see beyond that 
now thanks to your response.

Sincerely,

Jeffrey Brendecke

Managing Director
icanetix Software Systems and Consulting GmbH
Untere Hagenstrasse 26
91217 Hersbruck
Germany

Commercial Registry B 25317 Nuremberg, Germany
VAT-ID: DE250213502