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

[David Faure]

On Saturday 09 October 2004 19:43, Juergen Pfennig wrote:
> 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).

The function already exists, it's called KIO::probably_slow_mounted() 
(from kio/global.h). Can you check if it returns the correct value for you?
Then you should be able to make a patch that uses it to disable the 
things that are too slow for slow mounts.

E.g. the code looking for Icon in .directory files is in KFolderType::icon
(kdelibs/kio/kio/kmimetype.cpp). Konq also reads it (konq_mainwindow.cc:737,
and libkonq/konq_propsview.cc:190).

For KFileDialog, can you get a backtrace? I can't see code doing that.
kfiledialog.cpp says:
    locationEdit->setURLs( kc->readPathListEntry( RecentFiles ), [...] );
and KURLComboBox::setURLs() doesn't seem to check for existence.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).