[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDirWatch bug and the analysis. Help is welcome!
From:       Frank Reininghaus <frank78ac () googlemail ! com>
Date:       2013-08-01 10:44:57
Message-ID: CAFoZWWhZDkjYiAWbj32c2-w6V2w=Jzvij5wLaG3zPrxQDep81Q () mail ! gmail ! com
[Download RAW message or body]

Hi,

2013/8/1 Thomas L=FCbking:
>> We could, however, fix this by filtering out hidden files ("dot files") =
in
>> the KDirWatch inotify event handling, optionally.
>
> What doesn't help you when listing them as well.
>
> Questions:
> 1. why does dolphin update the .directory file *intantly* and esp. while
> still showing the dir. Why not when eg. leaving it or when closing down
> (bearing the risk to loose the update when "closing down" is a segfault)

I'm not quite sure (I haven't implemented the .directory thing), but
if the modified settings were stored when leaving the directory, then
splitting the view, opening a new tab, or a new Dolphin/Konqueror
window *before* leaving the directory would still show you the
directory with the "old" view properties.

> 2. why does that update block the GUI?
> Leaving all "view per folder pollutes itself" away, it's rather supoptima=
l
> if I can block the GUI by touching a file in a dir with many entries.
> QFileSystemModel is threaded, so why would it block the GUI?

I don't think that anything in KDE uses QFileSystemModel. It wouldn't
make much sense because that class is restricted to local file systems
AFAIK.

We (i.e., both Dolphin and KDirModel) use KDirLister to list directory
contents and be notified about changes, and KDirLister/KDirListerCache
is not threaded if I'm not mistaken. Changing that might be nice to
prevent such GUI blockings, but it might require quite a bit of work.

Cheers,
Frank
[prev in list] [next in list] [prev in thread] [next in thread]