pull request

[Dirk Hohndel]

On Aug 19, 2012, at 5:48 PM, Linus Torvalds wrote:

> On Sun, Aug 19, 2012 at 3:10 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>> I'll try to see if I can do that.
>> 
>> Feel free. I was going to tackle this tomorrow. But I won't mind if you
>> get to it first :-)
> 
> Ok, I have something that approaches being usable, but won't get
> around to finishing it today.

Sadly you didn't push it anywhere I could find it…

> I'm doing major surgery, and simply tracking the 'selected' status in
> the tree model. That way I currently actually get the case of
> "somebody selected a dive and then collapsed the group" case right
> too. The concept seems to work, and I track selections fine, but right
> now I don't fill in the old "selectiontracker" thing at all, so the
> things that use that won't work.

The nice thing about the tracker outside of the model is that it makes
iterating over the selected dives so much easier. But I'm not sure it's
worth keeping that information twice. Might be better to rework the code
that uses the selectiontracker infrastructure. It's only a couple of places,
anyway (statistics, for example).

> I'll finish it up tomorrow.
> 
> However, some behavior will end up being basically ambiguous. For
> example, let's say that we shift-select a range that covers a
> *partial* group. Now, gtk will select the group entry itself (because
> it's part of the range). Should that then mean that we select all the
> sub-entries (because the group entry itself got selected?
> 
> Or should we (for example) say "selecting a group selects the
> sub-entries only if the group was collapsed, and if it was expanded,
> you need to select the entries explicitly"?
> 
> I can do either, and I think either can be argued for. What is really
> hard for me to do is "selecting a range that includes the exploded
> group entry but not the whole group will mahically just select the
> partial group" _and_ "selecting only the exploded group entry will
> select the whole group". Why? Because I can't really tell the
> difference between somebody clicking things furiously by hand, and a
> shift-click that selects a number of entries in one go. So it's
> ambiguous whether I should select the whole group (because the group
> entry got selected) or whether I should just select a partial group.

The logic I had started to implement this morning when trying to track
this thing down (but I did this by extending the selection tracker and 
making the summary entries be unique with their negative index,
by giving them an index of negative-index-of-first-dive-in-the-group),
was that the summary entry selects the whole dive when the group
is collapsed, but not when it is expanded. So selecting ranges of
dives in the expanded state does the "intuitive thing" (I can use shift
click to select a partial group). 
To get this to be consistent the summary entry needs to be shown as 
unselected when only part of the group is selected (even if the shift-click
sort of extended over it).

> For a similar reason, when you go from non-date view to date view, I
> don't know if I should select the group header fields, because they
> didn't exist in the non-date selection at all. So right now, if you
> select everything in date view (which selects the group header lines
> too), then move to non-date view, and immediately move back, all the
> header lines get unselected (but all the individual dives stay
> selected).

I had this on my todo list as I consider that a bug. If all dives in a group
are selected, then the summary entry should magically get selected.

> These issues aren't any worse than what we currently have, I'm just
> bringing them up as "I can't make everything magically always do what
> a human might expect", because some cases are just ambiguous.

Agreed - what I described here is what I envisioned the logic to be.
Other implementations could be argued for - I think we should settle
for one and document the behavior.

/D