Don't deselect all dives on all selection "change" events

gtk sends the selection change events all the time, for pretty much any
"divelist changed - so selection changed".  The expansion of a trip, the
switch to a new model, yadda yadda.  But we actually want selections to
be sticky across these events, so we can't just forget all of our old
selection state and repopulate it.

So we re-introduce the "am I allowed to change this row" callback, which
we used to use to create a list of every actual selection that was
changed.  But instead of remembering the list (and having the stale
entries issue with that remembered list that caused problems), we now
just use that as a "that *particular* selection cleared" event.

So this callback works as the "which part of the visible, currently
selected state got cleared" notifier, and handles unselection.

Then, when the selection is over, we use the new model of "let's just
traverse the list of things gtk thinks are selected" and use that to
handle new selections in the visible state that gtk actually tracks
well.  So that logic handles the new selections.

This way, dives that aren't visible to gtk don't ever get modified: gtk
won't ask about them being selected or not, and gtk won't track them in
its selection logic, so with this model their state never changes for
us.

gtk selections are annoying.  They are simple for the case gtk knows
about (ie they are *visually* selected in the GUI), but since we very
much want to track selection across events that change the visual state,
we need to have this insane "impedance match".

Reported-by: Dirk Hohdnel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>

0 files changed, 0 insertions, 0 deletions