pull request

[Dirk Hohndel]

On Aug 20, 2012, at 6:56 AM, Linus Torvalds wrote:

> On Sun, Aug 19, 2012 at 8:03 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>> 
>> On Aug 19, 2012, at 5:48 PM, Linus Torvalds wrote:
>>> 
>>> 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…
> 
> It wasn't ready enough. But I have jetlag, woke up early, and finished it.

Still jet lag? You've been back since Wednesday!!!

> Well, "finished" may be the wrong word, but it's pushed out and works.
> It gets a lot of cases right, and the code is actually smaller and, I
> think, easier to understand.

Still reading through the changes - I like it so far. I'm not quite sure I have
wrapped my mind around the changes to the multi-dive edits, yet.

It definitely removes parts of the code that I didn't like very much - and
seems much more likely to be able to stay consistent.

> The whole "is the group heading selected after you do certain
> operations" things is ambiguous as mentioned, but I tried to choose
> reasonably sane choices.
> 
> So you can - for example - do something like this:
> 
> - in the expanded date view, select a range of dives that crosses
> dive groups, and does *not* select the full groups at the beginning
> and end

Verified that. Good.

> - collapse and re-expand everything, and the selection shouldn't change.

Ditto

> - sort by something else, and go back to the date view, and the
> selection shouldn't change.

That part seems to work, but I noted a related oddity:

If I sort by something else and select some dives, including one that is
a last dive of a dive group (i.e., the first dive that shows up below the 
summary entry), then after switching back the group summary entry is
selected. See here for example:



I think the summary above dive #46 should not be selected…

> - collapse, and select some other dives, and the selection should do
> the right thing, regardless of whether you do a whole new selection,
> or whether you start adding to the old one with ctrl-click.

I thought I saw an oddity here when randomly clicking, but wasn't
able to reproduce it.

> What does *not* necessarily always work sanely is the "range
> selection" when you have expanded groups, and the beginning or the end
> of the range is the group entry. It seems that gtks range-select logic
> gets confused by the fact that we selected some dives "behind its
> back" (although we obviously did tell gtk that we selected them by
> explicitly doing the "gtk_tree_selection_select_iter()" thing), and
> the range selection logic ends up doing sometimes odd things.

Maybe that's what I saw above - I know I mixed in shift-clicks as well.

> That said, range selection works fine for ranges of actual dives, or
> ranges of collapsed dive groups. It's only with expanded groups where
> we "fix" gtk's selection logic that the fixing seems interact badly
> with the gtk range selection (shift-click) logic. If you range-select
> from bottom up, it works correctly. Maybe we can work around that too
> some way.

That's the one that I reported yesterday. There's something odd with gtk
doing shift-click selections downward.

/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20120820/3771aa77/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2012-08-20 at 8.33.32 AM.png
Type: image/png
Size: 135195 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20120820/3771aa77/attachment-0001.png>