Display Behaviour Change on Trip Selection

[Dirk Hohndel]

On Feb 18, 2013, at 7:35 AM, Lubomir I. Ivanov wrote:

> On 18 February 2013 15:52, Amit Chaudhuri <amit.k.chaudhuri at gmail.com> wrote:
>> Lubomir, that seems to cure the "dive plot blanks" so it's an improvement
>> from my point of view.  Most stats seem ok too. :)
>> 
>> But the stats / dives counter is still a bit broken.  If the trip has 5
>> dives I get 5,5, 4, 3, 2, 1 as I click my way down from trip through each of
>> the dives.  Clicking back the other way I get 1, 1, 1, 1, 1, 5
>> 
> 
> just sent a new patch that tries to fix that.
> [PATCH] Select all dives in a trip when said trip is expanded and clicked

I'll take a look at the pending patches in about an hour or so...

> my previous attempt was very silly...
> the current fix does something else however, so there should be
> confirmation if this is desired.
> it is also quote inefficient.
> 
> when a trip is collapsed, we don't care if a row of an actual dive
> (child) is selected (GTK selection) and we can select it only as
> "data" using select_dive().
> but if the trip is expanded we might want to also select the rows (GTK
> selection).
> 
> i personally do not understand the need for separation here between
> dive selection (dive->selected) as data or as visual indication (GTK
> selection), unless some more complicated interaction is going on
> behind the scene. this is usually not a bad idea i must admit thought,
> but the naming of the functions should be more descriptive.

Yes, there is a very silly thing going on behind the scene. When a trip is
collapsed, Gtk forgets the selection state of the dives inside the trip. So
we started tracking selection ourselves. And every new implementation
(we are now on number 3, the last one having been done by Linus a few
weeks ago) appears to have another shortcoming - usually caused by 
our attempts to work around the issues with the Gtk implementation.
It's very hard to get Gtk to tell you what is actually going on… it has a
callback that is called for every dive that it thinks will be selected or
un-selected BEFORE actually doing that (this allows you to say "no,
don't select/un-select that dive), but then AFTER it changed visual
selection state for the dives, it gives you only one callback that says
"selection state on one or more dives may or may not have changed"…
And with all that and the interaction of collapse / expand and shift-click
and all that it is a real pain to get this to DWIM.

> most importantly the user _does not care_ if we have 3 different types
> of selection logic, of course.

Well, the user cares that the software does behave consistently and
at least somewhat logically. Having three dives in a trip selected,
collapsing the trip, expanding it again and having the dives unselected
is inconsistent and illogical.

The behavior that Amit described seemed to have some logic to it (as
long as you understand the implementation), but certainly wasn't very
consistent.

And I am aware of one silly issue in the current implementation (don't
know if your patch addresses this) that if you click on a trip when it
is collapsed, the dives inside are all selected. But if it is expanded and
you click on the trip, they are not.

> p.s. obvious semi-rant indicates that divelist.c may be soon ready to
> be nuked from far orbit :-)

Not sure - while gtk-gui.c did indeed contain separate UIs and it was 
somewhat reasonable to split those up, divelist.c seems to mostly
be about one widget that we have. While I agree that very long files
are bad, artificially splitting things up isn't an improvement, either.

/D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4130 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130218/f08e4a28/attachment-0001.bin>