Bug 293888

another usability issue:

In the gtk-filechooser, the filename in the input box is selected (without
extension) and the textbox has the focus. so i can either hit enter to save it
with this filename, or just start typing to replace the filename with a better
one.


still trying to collect, which are the things, which make the other filechooser
better. Its more like "okay, this one works quite nice, and this one seems more
complicated" and then you try to figure out what the real differences are.

okay, further ideas what the problems are:

- maybe disable icon-thumbnails by default and provide a preview-image on the right for image-save dialogs. then even in large folders only the preview of the image to be overwritten needs to be loaded.

- it seems generation of the filelist and maybe even starting of the thumbnailer are in the same thread as the Chooser-UI. At least the UI is blocked for serveral seconds depending on the number of files in the folder. It would be better to have this in a background thread, so a user which only wants to save some image just can type the filename in the dialog and click "save" without waiting for the list to be loaded.

I've the same problem.
When using Chrome 18.0.1025.168 (Developer Build 134367 Linux) on Ubuntu 12.04, the KDialog takes more than 1 minute to show up!

Qt: 4.8.1
KDE Development Platform: 4.8.4 (4.8.4)
KDialog: 1.0

When executed manually the following command:
strace kdialog --attach=71303405 --title=Open File --getopenfilename /home/kenorb/Sites/x/sites/all/modules/contrib/simpletest_clone

It seems to stop on poll for exactly 25 seconds!

write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}])
writev(6, [{"\225\24\31\0\32\0\300\5\1\0\0\0+\0\0\0\7\0\t\0\377\377\t\0\t\0\0\0\3648\0\0"..., 400}, {NULL, 0}, {"", 0}], 3) = 400
recvfrom(6, 0x7aef44, 4096, 0, 0, 0)    = -1 EAGAIN (Resource temporarily unavailable)
write(3, "\1\0\0\0\0\0\0\0", 8)         = 8
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\21\0\0\0\20\0\0\0\177\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 144}, {"\f\0\0\0org.kde.kded\0", 17}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 161
poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}])
recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\t\0\0\0\6\0\0\0=\0\0\0\6\1s\0\6\0\0\0:1.162\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 89
recvmsg(7, 0x7fff4ef79770, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
sendmsg(7, {msg_name(0)=NULL, msg_iov(2)=[{"l\1\0\1\0\0\0\0\21\0\0\0k\0\0\0\1\1o\0\5\0\0\0/kded\0\0\0"..., 128}, {"", 0}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 128
poll([{fd=7, events=POLLIN}], 1, 25000

Are you doing sleep(25) or something? Why?
It happens every time to me when I'm trying to upload anything on any site in Chrome browser.

Do you have remote folders in Places Panel?

no remote folders. The problem seems to be just a large list of images in the opened folder, which slow the filechooser down.

Just to confirm, by Filechooser you mean still KDialog? Because I'm confused if we're talking about the same thing. And if our problems is similar, or I should report separate bug?
I don't have any remote folders either.

Isn't the kdialog --getopenfilename Filechoser (as used by Google Chrome) the same as the default filechoser other KDE programs use as well?

I have the problem with chrome, as thats my usecase where i save images from chrome in my Photos folder, but i think the problem may exist for other programs with the filechooser as well.

the problem does not seem to be with remote lookups, but with displaying large file icon lists.

Thanks, I've created separate Bug 307049

good thing, because my problem IS NOT that the dialog itself does not open, but that the filelist needs long to be filled with icons and be responsive,

(In reply to comment #9)
[...] but that the filelist needs long to be filled with icons and be responsive,
Not only with lots of files, but like you said before "Even in folders with not so many files, the general snapiness is much slower than the gtk-filechooser firefox uses."

It's very annoying, when simple file chooser needs about 1 sec to pop up, even on fairly modern hardware, like 4 core SB @ 3.3.GHz

*** Bug 318477 has been marked as a duplicate of this bug. ***

I have the same problem when adjunt files with Kmail. It's annoying...

*** This bug has been confirmed by popular vote. ***

In my case Filechooser was slow (over 1 minute), because UpdateManager hangs due to a bug/poor design on their part, we can be stuck for up to 25 seconds, hanging all of KDED along with it. In other words, one of the KDE module is blocking the D-Bus system (all d-bus sockets are taken by some other buggy process which was using buggy library (UpdateManager)), especially when using network with proxy. Workaround was to kill the faulty process, in my case it was releasechecker (Python app).
Now releasechecker should be fixed, but the bugs can be everywhere else, as the whole D-Bus implementation and debugging features of it leaves much to be desired.
The easiest way to check what's faulty, is to kill/unload KDE modules one by one and check when it'll actually work.
See more details at:
https://bugs.kde.org/show_bug.cgi?id=307049

The problem here is that the file dialog is called via the kdialog command, instead of directly from the application, e.g. Chrome.

Even if it looks like a shell program only, kdialog is a "full" KDE application like all other KDE applications. It has to load kconfig, sycoca, mime, icon databases, initialize locale/translation/styling stuff, lauch KIO daemons, etc. Starting it will be slow.

*** Bug 309682 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> The problem here is that the file dialog is called via the kdialog command,
> instead of directly from the application, e.g. Chrome.
Nope.
1) I am using KDE, so all the daemons are already running
2) Filechooser-Components in KDE-Programs are slow, too. The problem are the many files in a folder, i guess suppose because of some thumbnailing/metadata reading process.

When I run

kdialog --getsavefilename /folder/with/4000/jpgs/

it takes several minutes for the dialog to become repsonsive. This is also what happens in Chromium and other programs. In practical terms, it's unusable.

However, putting an strace on makes it much faster:

strace kdialog --getsavefilename /folder/with/4000/jpgs/

@Niels
It's rather not possible that it will run faster when followed by strace. Only if you run it as a different user.
Could you check on which syscall it's freezing and paste it?

I've been working on this for some time now, it's quite hard to nail down. Sometimes the strace / no strace effect is clearly repeatable for an hour, then suddenly it's not. This is through reboots and with no major changes to the system. Sometimes the dialog is quick, mostly it's not. I've tried many things and read many pages, and while I haven't solved the problem, I think it has "mostly gone away".

I've been testing with kdialog from console, save image in Chromium, move image in Gwenview and more. These all appear to work or not work the same. I've never seen Dolphin block like this on any large folder.

Getting rid of gamin made no difference. Removing folders mounted with sshfs in fstab made no difference. Removing some KDE services in System Setting probably didn't do anything.

I can point to two things that apparently make the dialog work again, but it's much too cargo cult-ish for comfort:

- Removing and / or creating subfolders in the large folder, opening the dialog several times.
- Changing view. Tree view usually blocks the dialog, Short and Detailed don't.

I've now had a working system for several hours over several reboots. I'm sure the problem wil reappear as soon as I press "send"...

*** Bug 323368 has been marked as a duplicate of this bug. ***

Similar problem on Debian sid with KDE v4.10.5. This issue has been around for almost one year on my laptop with an nvidia graphics card.  It occurs to both command-line kdialog and application file dialog such as those used by Chrome, although it usually does not occur right after login. 

(In reply to comment #20)
> It seems to stop on poll for exactly 25 seconds!
Similar delay here. In my case it is 23 seconds of freeze (along with 100% CPU) after I run the following: 
strace kdialog --getsavefilename /folder/containing/2000/files/and/folders
After I run the command above without "strace", however, the kdialog UI hangs for a much longer period of time. (The UI is still not clickable and consumes 100% CPU. It is not until 190 seconds later that the UI becomes responsive. )

(In reply to comment #20)
> - Changing view. Tree view usually blocks the dialog, Short and Detailed
> don't.

In my case, Short View doesn't block the kdialog UI whereas other modes (Tree View, Detailed View and Detailed Tree View) do.

For those Chrome users who need a temporary workaround, consider adding the following line to you ~/.profile so that Chrome no longer uses kdialog: 
export NO_CHROME_KDE_FILE_DIALOG=1

Same problem here: kdialog and all applications using it hang for about 13 secs before running normally; for example when i run Dolphin (both command line or from start menu) the window appears immediately, but the contents only after 13 secs.
I experienced it on 2 machines, both running Fedora 18 x86_64 (kde 4.10); 
CPU never reached 100%.

(In reply to comment #24)
> Same problem here: kdialog and all applications using it hang for about 13
> secs before running normally; for example when i run Dolphin (both command
> line or from start menu) the window appears immediately, but the contents
> only after 13 secs.
> I experienced it on 2 machines, both running Fedora 18 x86_64 (kde 4.10); 
> CPU never reached 100%.

NOTE: I found that by disconnecting the ethernet plug, the kdialog windows revert working correctly; If the I plug back again, the strange behaviour appears again...

(In reply to comment #25)
> (In reply to comment #24)
> > Same problem here: kdialog and all applications using it hang for about 13
> > secs before running normally; for example when i run Dolphin (both command
> > line or from start menu) the window appears immediately, but the contents
> > only after 13 secs.
> > I experienced it on 2 machines, both running Fedora 18 x86_64 (kde 4.10); 
> > CPU never reached 100%.
> 
> NOTE: I found that by disconnecting the ethernet plug, the kdialog windows
> revert working correctly; If the I plug back again, the strange behaviour
> appears again...

I found what caused KDialog to hang in my case: my PC has 2 nics: eth0 and eth1 but only eth0 is plugged to the internal LAN; my machine have a folder exported to some clients via samba, and on smb.conf i changed the following line:

        interfaces = lo eth0 eth1

to 

        interfaces = lo eth0

and after restarting smb services the problem completely disappeared.
Hope this helps.

My PC has two interfaces (eth0, wlan0) and a vpn interface. vpn and wlan0 are connected, eth0 is not.

But i use neither samba nor NFS.

Its not a general kde problem. dolphin is very fast in the same folder, where the standard filechooser (i.e. from ksnapshot) is very slow.

*** Bug 342266 has been marked as a duplicate of this bug. ***

Is anyone able to reproduce this with KDE Frameworks 5.45?

With 5.44 it seems better. You can still watch the file list building for about a second and scrolling is a bit sluggish, but it is not hanging and I can select a file with a name I already know fast enough.

Its hard to compare to gtk now, because Gtk3 is much worse than the kde filechooser was when reporting the bug, there probably because of mime-magic on every file (which is a bit off topic, if kde isn't having the same issue here).

I can test 5.45 when debian testing gets it.

Thanks, please do! Even if it's not radically better in 5.45 vs 5.44, maybe we can call this fixed anyway.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Filechooser in a directory with many images and thumbnails turned off:

- The dialog does not hang anymore
- It causes a short time high cpu on one core
- Scrolling is sluggy for the first 5-10 seconds or so, then it gets better
- The first 5-10 seconds have a waiting pointer, which makes it harder to select a file, even when it is possible

This happens each time, but only the first time you see (noticable) hdd activity. So some stuff seems to be cached, but other things still happen each time you open the dialog.

It's kind of WORKSFORME, but possibly there is room for more improvement.

(changing status)

This problem usually manifested itself when one or more subdirectories were mounted on network filesystems.

That makes sense. We have a lot of blocking calls that don't handle mounted filesystems that well. Kai has been working on this; CCing him.

I just hit this bug when using VirtualBox (choosing an Iso image for a VM). Are there any updates on this?

(In reply to grannie from comment #38)
> I just hit this bug when using VirtualBox (choosing an Iso image for a VM).
> Are there any updates on this?

It's only been 10 years. Quit being so impatient. ;)

KDialog continues to be the slow bottleneck on my otherwise fast system.

GTK file chooser runs laps around it.

Generic Qt file chooser runs laps around it.

KDialog is hilariously slow, even for local filesystems. (Slow for network locations *and* local. It's just more noticeable for network shares.) What is KDialog even doing in the background? Examining every single file inside the current directory or something? Listing the contents of a folder should be a smooth process, just like we experience with GTK file chooser, or heck, using the terminal. I'm not even using thumbnail previews, and it's still crawls with KDialog.

One workaround I found in the meantime is to trick applications into using the GTK file chooser instead, but this doesn't work across the board.

Isn't this supposed to be part of the more generic Bug #178678 ?
Although the title makes it seem like it's Dolphin-specific, that's just the worst offender and the bug report was turned into a general KIO issue.

(In reply to flan_suse from comment #39)
> KDialog is hilariously slow, even for local filesystems. (Slow for network
> locations *and* local. It's just more noticeable for network shares.)

The issue is with latency-bound I/O strategies.
It should be really uncommon locally unless you are looking at an HDD which happens to get quite a bit of usage elsewhere too.

The file picker appears to show mounts, so it should be still affected by the problems of mounted network locations.
Not sure how often does that info get refreshed, but just a single mount not responding or being too slow can negatively effect user experience as discussed in Bug #454722 .

I am not sure if it is the same. I wouldn't want this bug to be closed if the other only resolves issues caused by network mounts but problem with local folders may persist.

The only thing that really helped getting rid of the 25 second delay for the file dialog to open was to set:

export GVFS_REMOTE_VOLUME_MONITOR_IGNORE=true

as per https://forum.manjaro.org/t/is-it-possible-to-bypass-a-directory-using-org-gtk-vfs-udisks2volumemonitor/121698

I don't know why this affected a KDE dialog, though; probably because I opened it from Firefox, which is a gtk app (with widget.use-xdg-desktop-portal.file-picker set to 1 in about:config).

I recently updated to Plasma 6 and this is one of the issues I encountered. I have some CIFS mounts. In Plasma 5 there was no slow down.