[PATCH] When only a dive trip is selected, select all the dives in the trip

[Dirk Hohndel]

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

> On Mon, Feb 18, 2013 at 3:43 PM, Linus Torvalds
> <torvalds at linux-foundation.org> wrote:
>>
>> This does a final pass after all the selection logic, and notices if we
>> have dive trips that are selected, but that have no dives in them
>> selected.  In that case, we assume that the user wanted to select all
>> dives in that trip.
>
> Btw, to see just how much of a "magic special case" this is, do this:
>
>  - select a dive trip (all dives in that trip get selected)
>
>  - one by one, de-select each individual dive (ctrl-mouse-click)
>
>  - as you de-select the last individual dive, we now have the
> situation where the dive trip is selected, but no dives under the trip
> - so our special-case logic triggers, and all dives get re-selected.
>
> And yes, I can fix this, by having the logic be that we *only* do the
> whole special case if the dive trip itself was in the set of entries
> that got a "selection might change" callback. But from a UX
> standpoint, I suspect we don't even need to do this all, since the
> user really has to *work* at triggering the special case this way.

I think it's fine to NOT fix this. Let's call it an Easter Egg instead
and be done with it. 

    "It's *MAGIC*! Look how much work we did to have this *FUN*FEATURE*
                        that the true fans can discover..."

something like that :-)

> My point really is that it's a magic special case, and while it fixes
> the normal behavior, the magic rules really are magic rules, and you
> can see them in action by doing odd things to trigger them other ways.
>
> So I'm not arguing against the patch (I think it does what people want
> in all the normal cases), I'm just pointing out how odd things are
> when we have to fight the native gtk selection rules, and make up
> these kinds of extra rules on top.

The patch is applied and pushed :-)

/D