[Qt-interest] QTreeView::scrollTo at application start

[Stephen Kelly]

Luis Garrido wrote:

> Thanks for your insightful answer, Stephen!
> 
>> I'm guessing the currentPathIndex is not valid. FSM is populated
>> dynamically AFAIK, which means that the row you want to scroll to is not
>> in the model yet when the application starts.
> 
> That's a good guess that set me on the right track, but it is a bit
> more difficult.
> 
> The problem is the asynchronous way the model rows are filled. First
> of all, scrollTo goes straight to the target, adding the intermediate
> folders. For instance, if I try to index("/var/tmp/kompoza/music/gig")
> this is the sequence of rowsInserted signals:
> 
> Rows inserted: / [0-0]
> /var
> Rows inserted: /var [0-0]
> /var/tmp
> Rows inserted: /var/tmp [0-0]
> /var/tmp/kompoza
> Rows inserted: /var/tmp/kompoza [0-0]
> /var/tmp/kompoza/music
> Rows inserted: /var/tmp/kompoza/music [0-0]
> /var/tmp/kompoza/music/gig
> 
> That's when index() returns.
> 
> And then it begins to fill the rest of "/" subdirectories, most likely
> to cache the first tree expansion:
> 
> Rows inserted: / [1-19]
> /selinux
> /usr
> /boot
> /mnt
> ...<snip>
> 
> When I issue the scrollTo command it begins to fill the gaps of the
> intermediate subdirectories to expand them:
> 
> Rows inserted: /var [1-17]
> Rows inserted: /var/tmp [1-13]
> Rows inserted: /var/tmp/kompoza [1-1]
> Rows inserted: /var/tmp/kompoza/music [1-1]
> 
> I'd say in this respect scrollTo doesn't work as intended for
> asynchronous models, so it shouldn't be considered reliable.

Do you mean that the initial scrollTo works, but that inserting the other 
directories into the model above the wanted item means that the wanted item 
is 'pushed down', so that it's not visible any more?

Indeed this is a difficult problem, and I can't think of a good way to 
handle it either. Even if you keep listening to the rowsInserted signal, and 
scrollTo each time, if the user starts interacting with the view before the 
model is fully populated, you want to stop reacting to that signal. Maybe 
the user wants to select a different item on this time etc. That's probably 
the solution we'll use in a similar situation in Akonadi.

> 
> It is difficult to envision a workaround for this, unless we assume
> that FSM only issues rowsInserted signals after a subdirectory has
> been _completely_ populated. In this case we could expand
> progressively the tree from the root on, monitoring the rowsInserted
> signals until we get one whose parent is the parent of our target
> directory. Then we can disconnect from the signal and use scrollTo.
> 
> But if FSM implementation allows for partial populations for long
> subdirectories the only way to reliably determine when the population
> has finished is to keep a separate list of the parent directory
> entries and "tick" them as they are inserted in the model.
> 
> I'd suggest for next versions of FSM that this issue is addressed by a
> specific signal (all asynchronous stuff should have a way to signal it
> has finished, otherwise it is very difficult to automate).

The thing is that new items in the filesystem could be created while the 
model is populating itself, and those have to be inserted too. I don't think 
there's a reliable 'fully populated' state in this stuff. There's always 
reasons that rows can be inserted or removed at any time.

All the best,

Steve.

> 
> A quick ugly hack is to issue two scrollTo commands separated by a
> reasonable amount of time.
> 
> As things stand now I don' t think it is worth the pain, I'll use
> QDirModel instead.
> 
> Cheers,
> 
> Luis