summaryrefslogtreecommitdiffstats
path: root/gtk-gui.c
diff options
context:
space:
mode:
authorGravatar Dirk Hohndel <dirk@hohndel.org>2012-08-17 15:03:57 -0700
committerGravatar Dirk Hohndel <dirk@hohndel.org>2012-08-17 15:08:50 -0700
commit9e9ba73b3d21c2184c16f3ba5cf3a71f7c662a55 (patch)
tree2096b0a2b805e27de66f6fb418b3e60f1b878ea7 /gtk-gui.c
parentbc1ff9a1213e4c2a0c135974cbce03bc7614d7b5 (diff)
downloadsubsurface-9e9ba73b3d21c2184c16f3ba5cf3a71f7c662a55.tar.gz
Another selection fix
The corner cases are getting more and more artificial. Without this patch, the following can happen: Select one or more dives in an (expanded) dive trip. Now collapse that trip with the little triangle. Select a different trip. The previously selected dive(s) are still part of the selection (as you can see, for example, in the statistics tab). With this patch the scenario above works as intended (all the dives in the new trip are selected), but we have another corner case: Just as before, select one or more dives in an expanded dive trip. Collapse that trip and ctrl-click on another trip. Now you lose the originally selected dives. Frankly, if you ctrl-click to add more dives to your selection - just don't collapse the trips the dives are in? As this new corner case seems even more artificial than the previous one, I consider this patch an improvement. But fundamentally I am just battling all the ways in which gtk's selection handling is messed up. When I get the selection call back I cannot tell if this is a new selection or an incremental selection (i.e., a shift-click or ctrl-click). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Diffstat (limited to 'gtk-gui.c')
0 files changed, 0 insertions, 0 deletions