Version: unknown (using KDE 3.1.1) Compiler: gcc version 2.95.3 20010315 (release) OS: Linux (i686) release 2.4.19-pre7 When I right-click a file or folder in a KDE Open or Save file dialog box, there is no action to open the item externally. For example, if I right-click a folder, I should be able to choose the "Open" action as I can in Konqueror, which would open the folder in a Konqueror browser. If I right-click a file, I should be able to open that file according to its MIME configuration. The right-click menus should be as full-featured as the right-click menus in Konqueror, but they aren't in the file dialogs. The way it is now, I have to open Konqueror manually and browse to the same directory and perform my actions there. It would be much easier if I didn't have to go to that trouble. The Windows Open/Save dialogs don't have these limitations, and I find them very useful in a variety of situations.
And that's also a security breach, in my opinion. In a locked down system, on which the administrator has gone to all the trouble of checking what applications are available, allowing the user to "browse" the system by right-clicking on any directory and opening Konqueror is undesireable. I know because I have seen that in Windows, on many situations in which their Explorer is not present in the menus, but which you can open just as easily. Besides, in my opinion, the Open/Save file dialog is to open or save a file or files, not to do file management. But this is me.
Well, the real problem imo is that Open/Save dialogs are technically separated from the usual Konqueror file browsing view while visually being very similar. The result is that both are handled separatelly, Open/Save dialogs lacking the usual huge flexible amount of rmb menu entries as well as the capability to drag and drop files. This separation is very artificial and forced for users, Open/Save dialogs in KDE can easily seem being unnecessarily limited and dumped down compared to the usual Konqueror file browsing view. (The security breach argument doesn't hold here imo. If Open/Save dialogs were technically just another view of Konqueror file browsing view they'd be locked down with the same setting just like any other Konqueror file browsing view.) Solution?
I think the improved consistency would be a great idea. Although AFAICS, it would require quite some work in kdelibs to implement this cleanly (this is not just a KFileDialog issue, IMHO - it affects e.g. kfind, ark too). I'm even willing to have a go at implementing it but I'm too busy right now :(
One reason this feature would be very useful would be when trying to identify files that the user would like to overwrite, for example. Usually the built-in "preview" pane of the file open/save dialog box is less than adequate for identifying files, so it's natural to want to open files in their associated viewer. Unfortunately, there's no option for this. Instead, I have to open Konqueror manually, copy the path from the file dialog to Konqueror, then open the file in Konqueror. It's very awkward.
Well the problem is back again with KDE4 of course. How can i reopen this bug?
Moving from "kio/kfile" component to "kfile" product, helps sorting out duplicates.