pull request

[Dirk Hohndel]

On Aug 19, 2012, at 2:41 PM, Linus Torvalds wrote:

> On Sun, Aug 19, 2012 at 2:20 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>> 
>> 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.
> 
> No, the documentation is clear about it: as mentioned, it states that
> the modification callback can happen whether a particular thing is
> going to be changed or not.

You are mixing up the definition of the two functions:

	gtk_tree_selection_set_select_function ()

	Sets the selection function. If set, this function is called before any node is selected or unselected, 
	giving some control over which nodes are selected. The select function should return TRUE if the 
	state of the node may be toggled, and FALSE if the state of the node should be left unchanged.

This is where I hook in the modify_selection_cb. The documentation clearly says "called before any node is selected or unselected"

You are thinking of the "changed" signal, where the documentation says:

	Emitted whenever the selection has (possibly) changed. Please note that this signal is mostly a hint. 
	It may only be emitted once when a range of rows are selected, and it may occasionally be emitted 
	when nothing has happened.

Which is why I'm not using that one to track selections anymore (you had used that in your 
implementation which I ripped out).

> You're just supposed to return true or
> false to say whether the change would be *allowed*. The fact that you
> use it to figure out if it will happen isn't how it's supposed to be
> done.

No, the documentation EXPLICITLY states that in order to implement your own
selection logic, you are supposed to use the "select function".

> So not technically a bug. It's just that the gtk selection for trees
> seems to not really be meant for this kind of hierarchical thing,
> which is why it acts wrong wrt the parent entry to begin with, and why
> you try to work around it in the selection-modified callback.
> 
> I think that we would need to (a) keep track of the parent state too
> (right now you only track the individual dives) and (b) *after* the
> selection logic, go through and see what changed - and if a parent
> changed, change the children at that point.

Regardless of what I said above, my guess is that your proposed 
workaround would indeed work.

> 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 :-)

/D