Which workaround for strange KFileDialog behavior (recent files on server)?

Juergen Pfennig info at j-pfennig.de
Sat Oct 9 19:43:19 CEST 2004


Hello,
I am working on a Multi-Media-Center Software (zapdvb) and from time to time I 
find strange things in KDE. This time the problem is the Open File Dialog.

When somebody regularely records movies from DVB, the next idea will be to set 
up a video server. Such a server will have several disks, disks would consume 
electrical power (which will cost as much as the disk itself after a few 
years). So the solution is to let the disks spin down if unused. Linux can do 
this, so long so good.

Now back to KDE. Think of an app that plays videos from that server (like 
zapdvb using MPlayer or Kaffeine does) and that the Open File Dialog is used. 
The dialog remembers a file history. After a while the history will have a 
lot of entries (around 10?).

No comes the bad thing: The user will notice after a while that it takes 
longer and longer until the dialog pops up (it can take a minute). The reason 
is: KDE seems to try to validate the "Recent File History" even if the files 
are not in a local file system. For our video server scenario this implies 
that usually all disks need to spin up and eventually need to be mounted (all 
together this can  take a minute). This behavior unveils a KDE design 
problem.

As a workaround in my application I simply remove the "Recent File History" 
entry from kdialogrc - but this is not a very good solution. Could you 
imagine some "checkIfFileIsLocal()" call in KDE? This call should 
canonicalize path arguments and compare it against a cached list of mount 
points. Any tips or ideas?

I should mention here that the proposed "checkIfFileIsLocal()" call should 
also be use by Konqueror which causes the same problem for  directory 
listings (algorithm: do not try to read .directory on remote volumes unless 
it is known the the containing folder was accessed before and cache 
any .directory information once that it was loaded).

Yours Jürgen


More information about the Kde-optimize mailing list