pull request

[Linus Torvalds]

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.

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 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.

              Linus