pull request

[Dirk Hohndel]

Linus Torvalds <torvalds at linux-foundation.org> writes:

> On Mon, Aug 20, 2012 at 8:36 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>> If I sort by something else and select some dives, including one that is
>> a last dive of a dive group (i.e., the first dive that shows up below the
>> summary entry), then after switching back the group summary entry is
>> selected. See here for example:
>
> Yes. This is one of those ambiguous cases ("should the group entry be
> selected when *some* of the children are selected, and some are
> unselected"), and the reason I picked the solution I picked is that it
> gets the common case of "single contiguous selection-by-date" right.
>
> IOW, do a contiguous selection of dives by date (but not at group
> boundaries), and collapse/expand the dates and/or shift to some other
> sort order and back, and in order for the selection to *stay*
> contiguous, the "group entry is selected" choice needs to basically be
> the same as "first entry in the group is selected".

I see. That's why I suggested yesterday that in expanded view the group
entry should ONLY be selected if ALL of the dives in the group are
selected.

Unless, of course, you can convince gtk to accept a third state (with a
different kind of shading) that implies "partially selected". Good luck
with that (no kidding - I looked into that as gtk does indeed support a
different shading when that pane doesn't have focus - but I wasn't able
to convince gtk to let me control that on a per-column basis).

> If you have a random (non-date-contiguous) group of dives selected,
> then that "first dive in group decides whether the group is selected
> or not" choice will result in somewhat odd pattern, but I felt that
> since the selection pattern in that case is random *anyway*, that
> doesn't matter as much as the case of having the common
> date-contiguous selections.

I understand your reasoning, I disagree with the conclusion you came to
:-)

> But yes, the choice is ambiguous, and there are other possible
> algorithms to decide whether a group entry should be selected or not.
>
> Anyway, right now the rules are (or should be - maybe I missed something):
>
>  - a *collapsed* group is selected if any of the dives within it are selected
>
>    This is important for two reasons:
>     (a) visual clue that there is something selected
>     (b) if we don't do this, then we hit the gtk "out of sight, out of
> mind" problem, where gtk doesn't know or care about the (hidden)
> selected dives, and then if we select something else, gtk will never
> give us a un-selection notice about the hidden dives.

This makes perfect sense.

>  - an *expanded* group is selected by default if the first dive in the
> group is selected.

That I disagree with.

>    This gives us that visually nice contiguous selection for
> contiguous dive selections (otherwise we might have the last
> partly-selected group entry unselected because there are unselected
> entries in that group, or we might have the first group entry selected
> even though the first few dives in that group are unselected).

That second problem you wouldn't have with my proposed algorithm.
And the first one may be visually odd at first but it makes perfect
sense once you think about it. Your current algorithm seems far less
intuitive to me...

> But notice the "by default" about the second rule (the first rule
> *should* be a hard rule). If the group is expanded, you can obviously
> do selection things on the entries in the group, and if you unselect
> the first dive, that will not then magically unselect the group. So
> with an expanded group, the user can override the default behavior,
> exactly *because* the group is expanded.

Urgs. That's even more ugly and inconsistent then. I can have the same
set of dives selected, but depending on how I get there, summary items
may or may not be selected?

I /really/ don't like that, Linus.

> So I agree that the selection behavior for group entries may not
> necessarily be "obvious", but I claim that there's at least some
> reason for the choices I made.

Again, I don't deny the reason, I think you did not come to the best
possible solution.

> Modulo bugs, of course. Always modulo bugs.

I thought all your code was free from bugs by edict. Oh ways, that's
ESR.

:-)

/D