BUG: multiple selections are lost when re-sorting

[Dirk Hohndel]

Well, on the flight I fixed one possible cause, I think. I'll play with 
it some more to see if my diagnosis is correct, but I think it explains 
at least the issue I am seeing - not sure about the one you mention...

/D



On February 19, 2013 8:02:34 PM Linus Torvalds 
<torvalds at linux-foundation.org> wrote:
> On Tue, Feb 19, 2013 at 7:18 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
> > This used to work.
> >
> > - Start Subsurface
> > - Select several dives inside one or more trip(s)
> > - change sort column (dives are still selected)
> > - change back to 'trip sort'
> > - only the 'selected_dive' is still selected
> >
> > As it happens, that first successful change of sorf column (from trips
> > to one of the others) appears to be the ONLY one where we keep the selection.
>
> It's worse than that: it is timing-dependent, and probably has
> something to do with how we create the divelist, and just how/when the
> trips get expanded, and the order in which we get the selection event
> callbacks from gtk when all of this changes.
>
> Try it with the test-dives instead of your own divelist, for example.
> You can often (but not always) switch back and forth forever, and not
> lose selection. But do it with a bigger set of dives, and you're
> screwed.
>
> So I can reliably do (for example) this with just the test-dives (ie
> doing "./subsurface dives/*"):
>
>  - select multiple dives in "trip mode"
>  - switch back and forth from trip mode to depth-sorted forever
>
> BUT:
>
>  - switch from depth-sorted to time-sorted, and *boom* now only one
> thing is sorted.
>
> And if I use my own dives, I can't even do the "switch just back and
> forth between trip mode and depth-sorted order" part.
>
> Yeah, it's a mess. The actual series of "selection_cb()" calls seems
> to be almost entirely random.
>
> Do I have any idea why? No.
>
>                   Linus