BUG: multiple selections are lost when re-sorting

Linus Torvalds torvalds at linux-foundation.org
Tue Feb 19 20:02:34 PST 2013


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


More information about the subsurface mailing list