pull request

[Dirk Hohndel]

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

> On Mon, Aug 20, 2012 at 9:19 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>> 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.
>
> Think it through. The *only* way to avoid that rule is by saying "if
> any dive at all in a group is selected, then we always force the
> group-entry to be selected". Because that has to be the rule for the
> collapsed group.

See my previous email. I disagree.

And I just saw your email that you hate the visual oddity. Let's just
say that I find that much more agreeable than the "sometimes the group
entry is selected, sometimes it isn't" mess that we have right now.

> So "consistency" is actually detrimental in that case. If you select
> (by hand) a single dive, it would be *very* annoying imho to
> force-select the dive group.

Yes. Which is why I keep it unselected in the expanded case.

> So now the "consistency" rule would need to be made more complex:
>  - for collapsed entries, the group-entry is selected if *any* dive in
> that group is selected

Yep

>  - for expanded entries, the group-entry is selected if *all* dives in
> that group are selected

Yep

> You can make that consistent, and not overly annoying.

That's what I am proposing.

> But that doesn't work well either. Why? Because it screws up the
> "select by range" in the date view. You select a date view, and the
> *last* group entry isn't selected. Ugh. Ugly. Visually very
> inconsistent.
>
> So the current choice gives the visually best solution without
> unnecessary "select stuff behind the users back". And the one case you
> complain about is the odd case when you switch between views, not a
> *normal* case.

So we have to agree to disagree and you as the maintainer get to keep
your (IMHO, suboptimal) choice.

/D