Version: (using KDE 4.2.90) Installed from: SuSE RPMs Currently KDE provides two _different_ dialogs -- file and directory -- despite the purpose of those is very similar. A lot of feature from file dialog makes perfect sense in directory dialog -- showing places pane, zooming in/out, etc. Some of them are valid, but not that useful -- previews, going up, etc. But the main point is -- introducing two different dialogs, where could be virtually one (only the main pane could differ) increases complexity of KDE. User has to learn more, guess where to find feature A (or think why it is not present), and so on. Uniform look matters, so please reshape directory dialog just like file dialog with exceptions which are _necessary_, but not more.
*** Bug 199121 has been marked as a duplicate of this bug. ***
*** Bug 435290 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/531
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-integration/-/merge_requests/208
Git commit 72aed4172887a36b6b0a997ae736df422dbcb04f by Akseli Lahtinen. Committed on 23/03/2026 at 13:00. Pushed by akselmo into branch 'master'. (Qt5) Remove KDirSelectDialog and KFileTreeView, use KFileWidget instead There should not be any need to have separate dialog for directories and files. We can use same KFileWidget for both. Related: bug 515728 M +0 -9 qt5/autotests/CMakeLists.txt D +0 -46 qt5/autotests/kdirselectdialog_unittest.cpp M +27 -0 qt5/autotests/kfiledialog_unittest.cpp M +0 -2 qt5/src/platformtheme/CMakeLists.txt M +64 -67 qt5/src/platformtheme/kdeplatformfiledialoghelper.cpp D +0 -651 qt5/src/platformtheme/kdirselectdialog.cpp D +0 -114 qt5/src/platformtheme/kdirselectdialog_p.h D +0 -204 qt5/src/platformtheme/kfiletreeview.cpp D +0 -110 qt5/src/platformtheme/kfiletreeview_p.h https://invent.kde.org/plasma/plasma-integration/-/commit/72aed4172887a36b6b0a997ae736df422dbcb04f
Git commit 154d033939a137fde3af1976ab38e18a4074a5ad by Akseli Lahtinen. Committed on 23/03/2026 at 13:00. Pushed by akselmo into branch 'master'. (Qt6) Remove KDirSelectDialog and KFileTreeView, use KFileWidget instead There should not be any need to have separate dialog for directories and files. We can use same KFileWidget for both. Related: bug 515728 M +0 -9 qt6/autotests/CMakeLists.txt D +0 -45 qt6/autotests/kdirselectdialog_unittest.cpp M +30 -9 qt6/autotests/kfiledialog_unittest.cpp M +0 -2 qt6/src/platformtheme/CMakeLists.txt M +69 -74 qt6/src/platformtheme/kdeplatformfiledialoghelper.cpp D +0 -636 qt6/src/platformtheme/kdirselectdialog.cpp D +0 -114 qt6/src/platformtheme/kdirselectdialog_p.h D +0 -204 qt6/src/platformtheme/kfiletreeview.cpp D +0 -110 qt6/src/platformtheme/kfiletreeview_p.h https://invent.kde.org/plasma/plasma-integration/-/commit/154d033939a137fde3af1976ab38e18a4074a5ad
I just wanted to record one desatisfied voice: I like the folder tree dialog and for me it makes more sense when selecting a folder. It isn't perfect and has some bugs that I hoped could have been fixed, but I find the GNOME way of using the "Open File" dialog to select directories to be confusing and annoying - when trying to choose a directory you have to select a directory, and then when you click "Open" the dialog enters the directory and you have to click "Open" again to actually select it. Moving to that implementation is not an improvement, IMHO. The folder tree dialog lets you more easily understand your folder structure - which is more important when you need to select a directory.
I'd like to concur with Oded's comment. I didn't see anything wrong with the tree widget to select a directory, if anything, it helped to know that the program was definitely asking for a file or folder (tree) selection. Win32 had this for decades, but KDE's implementation (bookmarks, drag-and-drop) was superior. I haven't tested the new functionality yet - If it preserves the same click pattern (clicking "Open" accepts the selected directory and does not enter it) then I might be OK with the change. If not (as Oded's comment suggests), I'd see that as a regression and annoyance too.