pull request

[Dirk Hohndel]

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

> On Mon, Aug 20, 2012 at 9:35 AM, Henrik Brautaset Aronsen
> <subsurface at henrik.synth.no> wrote:
>>
>> For whatever it's worth, I agree with Dirk here.  I don't like having the
>> group entry selected just because I select a random (or in this case: the
>> first) entry.
>
> Try it. That's not AT ALL what happens.
>
> When you select the first entry, guess what gets selected? The first
> entry. Nothing more.
>
> In fact, when you select any dive at all, the *only* things that get
> selected are those particular dives.
>
> Dirk's rule is the one that does random things under *normal*
> circumstances. Like the following trivial scenario:
>
>   "If I select a random dive, and it just happens to be in a group
> with just one entry, it would now select the group too. But not if
> it's grouped with other dives".
>
> Sure, you can call that "consistent" (because it follows a rule), but
> it's visually *annoying*.  And it's "consistent" exactly the same way
> the current rule is consistent. Except the thing that people seem to
> dislike about the current rules doesn't actually happen *normally*,
> while Dirk's suggested rule affects *normal* behavior.

I would consider this quite logical and expected. Why? Because it always
does the same thing. If a trip is expanded its group line is selected if
and only if all the dives in the trip are selected. Easy, straight
forward, trivial to document.

Your solution is: if some (or even all) dives in a trip are selected then
whether or not the group entry is selected depends on how you got here.

> Btw, that leads to actual implementation problems too. For example, it
> screws up the "select range" behavior. Try implementing Dirk's rule,
> and I pretty much guarantee that you can no longer reliably select
> ranges.
>
> Why? Because when you select a dive, it may now select the dive group
> header too. As a result, when you shift-click on the second dive,
> you'll now have some seriously odd behavior, because the gtk
> shift-click rules seem to be based not on "what is selected now", but
> on "what was the last thing you *clicked* on".  It's why we have
> problems with range-select of exploded groups right now.

I haven't looked at the implementation quirks.

> I tried many things yesterday and this morning to get selection
> working. The current model *works*. You can do reliable
> range-selection, for example, you just need to be aware that you
> should do it by clicking on the dives (or on *collapsed* groups). It's
> not perfect, but the choices it makes are actually sane, and give you
> nice behavior for the common cases.
>
> You do realize that the behavior Dirk complains about is literally for
> a very special case (moving from non-date view to date view)? And that
> the "fix" for that special case ends up being a generic one that you
> will hit all the time.

You do realize that this is because you take YOUR normal workflow as
"the common case". And what other people do (I, for example, often look
at things like "all the dives deeper than xx ft" or "all dives where I
carried less than xx lbs of weight" and then switch back into date mode
to look at the trips during which I did those dives) as the "odd, weird
case".

Reminds me of the Gnome3 guys telling you that you were odd because you
wanted to have an easy way to start a new console app instead of doing
what they thought was the normal case, which is get your already running
console app. And they were happy to explain to you why your use case was
odd and it was ok to make it a pain in the rear to get what you wanted.

What I'm trying to say is: I understand that you like your solution
because it seems the most consistent for the things that you usually do.

Except that I think it does something very odd for the things that I
often want to do.

But as I said before, just like the Gnome3 developers get to make their
picks and you get to complain, here you get to make your pick and I get
to complain. :-)

(and yes, there may be implementation issues in my solution that I just
haven't looked into - but that's besides the point)

/D