Version: (using KDE 4.3.0) Installed from: Ubuntu Packages Steps to reproduce: 1) Open ksnapshot and create a screenshot. 2)Press "Save As", click on "Home", and click on the background of the directory list. 3) Now you can do a quick keyboard navigation. Enter the directory name in which you want to change. Then press ENTER. What the user expects to happen: One would expect that you only change into this directory when pressing ENTER. What actually happens: The open dialogue does not only change into the directory, but saves also the file in this dir afterwards. This is unintuitive. If the cursor / focus is in the directory list ENTER should only be used for the navigation in the directory tree. Only when the user changes to the filename input field (by pressing TAB) and press ENTER would the user expect the file to get saved.
I agree. I work almost exclusively with the keyboard, but for saving files I currently have to use the mouse because of this bug. That's a very annoying.
Proposed fix http://reviewboard.kde.org/r/3435/
SVN commit 1111606 by wstephens: This patch solves the problem that the Enter/Return keys cannot be used when saving files to navigate into a folder in KFileDialog. What happens is that the navigation in KDirOperator works, but the key event is also caught by the KFileDialog itself and passed to KDialog, oking the dialog. Cursoring over a file in the KDirOperator populates the location widget, so a filename is provided and the dialog is valid. This patch consumes the Enter/Return key event in a new KDirOperator::keyPressEvent(QKeyEvent*). This change should be sufficient to solve the problem, but past changes to the code have made the control flow complex and different when loading and when saving files. Without the Enter/Return key press event reaching KDialog, the user cannot save a file by selecting it and pressing Enter. This is for 2 reasons: 1) r891277 by ereslibre in KFileWidget::_k_fileSelected() prevents the KDirOperator::fileSelected() signal from invoking slotOk(), to "give the user a chance to amend the filename after selecting a file". 2) r895027 by ereslibre suppresses the KDirOperator::fileSelected() signal from being emitted when the isSaving flag is set on KDirOperator, when an item is activated, in order to respect KDE's double-click/single-click activate policy. This is redundant because QAbstractItemView::activated() is controlled by KStyle according to KDE click policy (http://apaku.wordpress.com/2008/06/23/itemviews-with-kde-styles-adhere-to-kde-settings/). Since the behaviour change in 2) to KDirOperator::fileSelected() was masked by the propagated Enter/Return, is redundant for its goal, and was undocumented, the patch removes it. The additional chance to amend the filename behaviour is inconsistent with single click policy and gives different behaviour in between load and save mode, but is useful since no select/deselect buttons appear on hover in KDirOperator's views yet, so I have kept that and improved it by focusing the location widget after a file item is activated. BUG: 205781 M +8 -1 kdiroperator.cpp M +2 -0 kdiroperator.h M +3 -1 kfilewidget.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1111606
*** Bug 115251 has been marked as a duplicate of this bug. ***