[Patch] Bugs in KDev-3.4's cvs-part (Part 2)

[Andreas Pakulat]

On 04.05.07 11:23:04, Robert Gruber wrote:
> But while implementing the read from the local CVS/Entries file I ran 
> into another problem. The FileTree part requests the status everytime 
> the expanded() signal of a directory-item is executed. When the directory 
> is expanded for the first time, the directory-item does not contain any 
> childs at the time the CvsFileInfoProvider gets called. The childs seam 
> to be created async (but I wasn't able to find out how). The reading from
> CVS/Entries file is so damned fast, that the CvsFileInfoProvider sends 
> the status back to the FileTree even before it has added the childs to 
> the directory-item. No problem here when calling "cvs status". The 
> dcop call is pretty slow so it seams there is enough time for FileTree
> to create the childs.
> So in the slot VCSFileTreeWidgetImpl::vcsDirStatusReady() no childs will 
> be found for the directory-item and the FileTree will therefore ignore the
> status that has been reported by the CvsFileInfoProvider. When I then 
> close and re-expand the directory-item, the status-update works 
> because the childs have been created in the previous run.
> 
> I found no other solution than holding back the statusReady() signal a 
> bit using QTimer::singleShot(1000,...). But this looks quit ugly to me. 
> Hopefully anybody has a better solution?

No, because we don't have full control over the creation of the childs.
There's only a hook (VCSFileTreeBranchItem::createTreeViewItem) that
will create the treeview item from the file item. But how fast this gets
called depends on some KDE class (KDirLister or something related). So
unfortunately I think the singleshot timer is the only option we have.

Of course one could implement caching of the status data and then apply
the status data in the createTreeViewItem, but I think such a change
should wait until after the release as its too intrusive.

Andreas


-- 
Save energy: be apathetic.