Change in behavior of kdialog -getexistingdirectory /example/dir

The behavior of kdialog -getexistingdirectory seems to have changed after the last update to version 23.04.0.

Previously, when I passed /example/dir as a parameter, the dialog with directory tree appeared and the passed directory was automatically selected, so I could confirm with ok.

Now the dialog opens and it shows the content of the passed directory and I have to go back one level and then select the directory and confirm with ok.

How do I get the old behavior back?

This problem is reported in issue ticket 472715 – KDialog shows file selector instead of folder selector

As far as I can tell there is no way to get the old behavior back - except maybe through a fix to bug 472715.

Are you sure that bug report is chasing up the right tree…

The commit that apparently was the cause was merged 6 years ago - and was contained in 17.04.3 and on… Surely it would have been noticed before now…

Are you sure it isn’t closer to this - which addresses - and I quote “some systems” … Maybe it screws up others that were acting correctly for 6 years?

I’m pretty sure that isn’t it - changing the “file mode” is a very minor change (read the FileMode docs here) - it doesn’t change the whole look and feel of the dialog, but even if it did - it looks like changing from “any file” to “directory” should have been a move in the right direction.

Regardless, I wrote, tested and pushed an MR for (kind of) reverting 633667a373a690e636c6d7c231c0d9700f62473b and that looks to do what was requested: have a directory tree selector.

@Angus I stand fully corrected. QFileDialog that the commit I pointed at added is the correct approach, but MR 17 you’ve pointed it added the FileMode in the wrong place - when it was added after setOptions(), it reset the options and caused QFileDialog to not use the directory only selector.

Possibly, or it worked at the time and Qt had a behavior change :person_shrugging: .

Anyway, I fixed the MR to fix the problem.

This issue has now been solved in the repository, but will probably only be fixed for Plasma 6.

Out of curiosity. Is it?
Not that I intend to jump on 6 shortly, but the issue has been around for a long time. Me personally, I made a bunch of scripts and servicemenus that use the dialog and are totally useless. Some of which, combined with other issues are a real pain. For example, the copy/move servicemenu entry is nowhere to be seen on the desktop. It is in the desktop directory in dolphin, but not on the desktop.
Therefor I made me a couple of servicemenus to overcome the nuissance. Halas… So yeah, I hope at least one of those particular issues is solved in 6 cause the desktop will remain partially crippled.

Yes, it is solved:

1 Like