Accepting or rejecting whenever QFileSystemModel is emitting dataChanged?

[neosettler]

Greeting,

After implementing a fairly complex file browser (Windows style), I realized that dataChanged is emitted quite often and surprisingly, when there is no apparent reason to do update anything. One would say that this is no big deal but it become very apparent while dealing with several thousands of files, freezing the entire app for about a second. The reason why it is quite heavy on process is that each file have to validate their source controlled states inside QFileSystemModel::data.

In any case, the more obvious dataChanged I would like to prevent form happening is when QFileSystemModel parent widget (I presume) is Entered or Leaved. I tried to filter and catch who is triggering the dataChanged but with no luck so far. Any hint on why would dataChange being triggered at this moment might be helpful to track and prevent it form happening.

In the event where we cannot prevent the dataChanged from occurring, would it be possible to move the QFileSystemModel::data to a separate thread? If yes, how would this be accomplish?

Thank you,

[d_stranz]

Are you checking the index range and roles that are part of the dataChanged() signal to see if they apply to the entries you are displaying in your browser?

Are you doing something in your "validate their source controlled states inside QFileSystemModel::data" code that could cause a file system watcher to think that the file / directory has changed? For example, are you changing an icon when you determine that the file is source controlled?

Users have become accustomed to "live" file updates in file browsers. If you turn off updating, this will probably annoy your users.

would it be possible to move the QFileSystemModel::data to a separate thread?

I think you would be better off if you changed your model to cache the source control state. This is likely something you could do in the background (eg. in a thread) and emit signals to update the UI periodically instead of for every file.

[neosettler]

Thank you for your input d_stranz, very appreciated.

Are you checking the index range and roles that are part of the dataChanged() signal to see if they apply to the entries you are displaying in your browser?

I think so yes:

QVariant QT_BrowserModel::data(const QModelIndex &in_index, int in_role) const
{
	if (in_index.column() == 0)
		if (in_role == Qt::DecorationRole)
 
...

QVariant QT_BrowserModel::data(const QModelIndex &in_index, int in_role) const
{
	if (in_index.column() == 0)
		if (in_role == Qt::DecorationRole)

...

To copy to clipboard, switch view to plain text mode 

Are you doing something in your "validate their source controlled states inside QFileSystemModel::data" code that could cause a file system watcher to think that the file / directory has changed? For example, are you changing an icon when you determine that the file is source controlled?

Yes, I do a QPainter "overlay" on the thumbnails BUT, even if no files are being modified, it still tries to refresh the model's data on cursor enter or leave anyways. On that note, I get the same behavior (but faster) when I emptied QFileSystemModel::data and QFileSystemModel::setData. Maybe when QFileSystemModel parent's is getting focus... a QFileSystemWatcher is being triggered? If yes, would it be possible to catch and silence it somehow?

Users have become accustomed to "live" file updates in file browsers. If you turn off updating, this will probably annoy your users.

Agreed.

would it be possible to move the QFileSystemModel::data to a separate thread? I think you would be better off if you changed your model to cache the source control state. This is likely something you could do in the background (eg. in a thread) and emit signals to update the UI periodically instead of for every file.

Keeping into account that the "live" file updates is needed, would the cache still be forced to validate itself whenever an unwanted dataChanged is called? While this sounds like a neat solution I have little to no ideas how it would be accomplish... so feel free to elaborate on this concept. Note, I'd like to build on a nearly working mechanic rather than starting a new one. That said, I'll consider this approach nonetheless.

Thank you,