[KDE Usability] Review Request: Add "Open File Manager" action to KFileDialog toolbar

Diego Moya turingt at gmail.com
Mon Feb 1 18:39:16 GMT 2010

On 31 January 2010 19:33, Harsh J wrote:
> Uh, its not item-selection based as I pointed out. It is simply "Open File Manager" -> no "in". No matter what you select or where you right click in that view, it'll show this option cause it opens that current viewing _directory_ in the default file manager, not readme.txt or anything else.
> This was also the reason why I wanted it as a tool button since it isn't item/type/selection-sensitive.

This is valid reasoning. This action pertains to the dialog, not the
selected file, so it makes sense to have a button for it visible in
the dialog.

> Anyway, there's enough patches here now to just revert back to the Open With thingy, so its upto the usability experts - I'll wait around to see if I could fix anything else regarding either :P

I'm biased, given I asked for this feature. I would suggest having an
"Explore" button next to the "Open" and "Cancel" ones: this action
creates a new window, so it's more related to the buttons to finish
the dialog's workflow than to the button toolbar (which modifies the
current dialog state).

>> On 2010-01-31 00:08:03, Markus Slopianka wrote:
>> > Right now (in 4.4) the KFileDialog context menu is totally useless. It contains view options (that can also be reached via the Wrench button), the option to delete a file, and Properties. Some additional items, like Open With would at least give the context menu some purpose. And as the Open With context menu is already familiar to the users from Dolphin, it's IMO even better for the usability than introducing a totally new action.

I'm not really opposed to the "Open With" action in the context menu
for files. I raised the "slippery slope" argument that adding features
to the KFileDialog ultimately turns it into Dolphin. So why make the
distinction then? - just open Dolphin when the user wants to open a
file in the current application. (Actually this idea is not without
merit - but exceeds the scope of the current thread).

More information about the kde-core-devel mailing list