pull request

[Dirk Hohndel]

On Aug 19, 2012, at 12:21 PM, Dirk Hohndel wrote:

> Yep. And I think I can tell that we are being called while expanded and therefore adjust the tracking logic.
> Basically, if we are expanded and the whole group is selected, don't manually unselect the children.

Nope, that analysis is wrong. We already do the right thing when called, 
regardless of whether we are expanded or not.

Right now I think this is a genuine gtk bug.

When expanding a selection gtk sends unselect events for all selected 
rows, then select events for all, including the new ones (don't ask me 
why it does that).

When you move "up" in the tree list (so you shift-click to add a "later" 
trip in the default sorting order), then everything works fine. You get 
unselect events for the summary row and all of the actual dives, and 
then you get select events for all the summary dives and all their 
children that now should be selected.

But if you move "down" in the tree list with the shift-click, you get all 
the unselect events and then select events for only the LAST (in the 
"order of rows"-sense) of the previously selected dives.

Why do I think this is a bug? In the exact same scenario, if you 
Ctrl-click on the next summary, all works as expected, we get the 
correct sequence of events and do the right things. Even though from 
a program logic point of view the shift-click should do exactly the 
same as a ctrl-click.

Now I could of course hack around this bug. Use a timeout to detect 
event groups and if all my dives get deselected, the last one gets 
reselected and more dives get added, then add all the other previously 
selected dives…

But I think that would be a really ugly hack. I'd rather figure out what's 
broken in gtk (or maybe in the way we use gtk… it's always possible 
that this is our fault in some other way…)

comments?

/D

> Linus Torvalds <torvalds at linux-foundation.org> wrote:
> 
>> On Sun, Aug 19, 2012 at 11:52 AM, Dirk Hohndel <dirk at hohndel.org>
>> wrote:
>>> Yes, I think I know what's going on.
>> 
>> I think I do too.
>> 
>> I *think* the problem is introduced by the fact that you change the
>> selection by hand when the group is selected, so what happens is:
>> 
>> - gtk tells you that the group is selected: you as a result
>> recursively select all the children.
>> 
>> - gtk *also* tells you that the children are selected (because it's
>> expanded and you shift-clicked, so gtk wants to select everything in
>> between), but you've already selected the children, so now when you
>> get that callback, you *unselect* them because that's how you react to
>> the "selection change" signal.
>> 
>> Or something like that.
>> 
>> I get the feeling that we're a bit screwed, because I don't see that
>> we have any way to control the order that gtk sends that "change"
>> callback to us. In fact, the documentation states that the "change"
>> callback can happen even if no change really happened, and I think
>> that's why one of the entries stays selected in the end: the debug
>> output shows that the shift-select click results in
>> 
>> 
>> modify_selection_cb with idx 234 (according to gtk was selected)
>> remove 234 from selection of 2 entries
>> removed 234 at pos 0 and decreased amount_selected to 1
>> currently selected are 233
>> modify_selection_cb with idx 233 (according to gtk was selected)
>> remove 233 from selection of 1 entries
>> removed 233 at pos 0 and decreased amount_selected to 0
>> currently selected are
>> modify_selection_cb with idx -1 (according to gtk was selected)
>> modify_selection_cb with idx 233 (according to gtk was unselected)
>> add 233 to selection of 0 entries
>> increased amount_selected to 1
>> currently selected are 233
>> modify_selection_cb with idx -1 (according to gtk was unselected)
>> modify_selection_cb with idx 232 (according to gtk was unselected)
>> add 232 to selection of 1 entries
>> increased amount_selected to 2
>> currently selected are 233 232
>> modify_selection_cb with idx 231 (according to gtk was unselected)
>> add 231 to selection of 2 entries
>> increased amount_selected to 3
>> currently selected are 233 232 231
>> 
>> (notice how 233 showed up *twice*)
>> 
>>          Linus
> 
> -- 
> Sent from my phone.
> Please excuse my brevity and text prediction errors
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface