[Interest] Why are selections not preserved in QListView when resorting?

[Philipp Kursawe]

I imagine, as often, its not a lot of code, but I wonder why this basic,
expected behaviour is not in all the selectable views in the first place?
I like to use PersistentIndex a lot in my background data update code, so I
will try to come up with a solution here. I will post the code later.


On Tue, Nov 12, 2013 at 3:08 PM, Bo Thorsen <bthorsen at ics.com> wrote:

> If you need to do this, it's actually not hard to do.
>
> Catch the sort just before it happens. Grab the current selection. Map
> the indexes to the source model. Sort. Remap the indexes to the new
> selection. Apply to the view.
>
> It might look at bit complicated in text, but the code is
> straightforward and easy to do.
>
> You can probably make it even simpler by using a persistent index.
>
> It's been years since I last did this, so I can't give you more details.
> But I remember that it wasn't hard to do.
>
> Bo.
>
> Den 12-11-2013 14:16, Philipp Kursawe skrev:
> > Thanks André. It's things like this that make me wonder if we have
> > chosen the right framework from time to time. Given that the Win32
> > ListView has all this functionality and much more what Qt has to offer.
> > But then Win32 API has no concept of signals/slots like this, but one
> > could certainly mimic it using the Windows message loop.
> >
> >
> > On Tue, Nov 12, 2013 at 2:00 PM, André Somers <andre at familiesomers.nl
> > <mailto:andre at familiesomers.nl>> wrote:
> >
> >     Philipp Kursawe schreef op 12-11-2013 13:46:
> >      > There seems to be no concept of selection preservation in
> QListView
> >      > (an probably other QAIViews).
> >      > When I select the second element and then re-order the list, the
> >      > selected item is still the second (index) but models data on
> index 2
> >      > is not the same anymore.
> >      >
> >      > Am I doing something wrong?
> >     No, I don´t think you´re doing anything wrong. QSFPM is.
> >     The problem is that resorting isn´t using the
> beginMoveRows/endMoveRows
> >     methods. The QItemSelectionModel has no way to know that the items in
> >     the model have moved. It has no concept of there being an underlying
> >     model that your _really_ looking at. By using the move signals, QSFPM
> >     could in principal signal that items have not changed or the model
> >     reset, but items merely have moved, and QISM could use that signal to
> >     update itself, but again: it is unfortunately currently not
> implemented
> >     that way.
> >
> >     André
> >
> >
> >     _______________________________________________
> >     Interest mailing list
> >     Interest at qt-project.org <mailto:Interest at qt-project.org>
> >     http://lists.qt-project.org/mailman/listinfo/interest
> >
> >
> >
> >
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
>
>
> --
> Bo Thorsen, European Engineering Manager, ICS
> Integrated Computer Solutions. Delivering World-Class Applications
> http://ics.com/services
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131112/0a5e5daf/attachment.html>