Version: (using KDE Devel) Installed from: Compiled sources Hi all! If I use ALT+Cursor_left, ALT+Cursor_right or ALT+Cursor_up in a KFileDialog the keyboard focus currently stays where it was before. It would be nice if the KDirOperator got it instead - regardless (almost-see below) what widget had it before. So I could further navigate to my target without having to hit the tab key several (depends on where focus is) times. The exception should be the path combo (i.e. the text field (KURLComboBox) showing the current path). If it has the keyboard focus it should keep it when the path changes, because this may well happen when the path was edited in the combo. This way I could use e.g. ALT+Cursor_up as an editing aid to strip the last path component and then perhaps add another. Patch follows
Created attachment 3639 [details] give KDirOperator 'some' focus Long story short patch :-)
In which cases does this make an improvement? By default the focus is on the path combo, so in the default case it doesn't change anything... I don't like to switch focus somewhat arbitrarily if there isn't a clear advantage.
>By default the focus is on the path combo Is it really? If I (newly) open a KFileDialog the focus is initially in the text field labeled "Location". If the focus is on the path combo before I chdir somehow (i.e. using said ALT+Cursur* combinations or a shortcut from the list) then the path combo keeps focus. I do not want my patch change that behavior. However if the focus was somewhere else then the KDirOperator should now get it. This would support at least _my_ normal mode of operation in a file dialog: 1. Go to or near the target directory using shortcuts 2. If necessary, further navigate through directory structure using the KDirOperator (without the patch one now has to activate the KDirOperator by clicking at it or iterating with tab key) 3. Choose a file by highlighting it and press Enter or press tab to use the "Location" field If one just uses the mouse the patch shouldn't matter. With keyboard navigation the new behavior saves a few key strokes.
Ah, sorry. I had the path combo (With the directory at the top) confused with the location combo. I still don't agree with your proposed change though, it would be rather annoying if you want to use the Location combo to select a new directory (and take advantage of the completion feature in it) and it lost its focus when you went a directory up. What you basically seem to want is an easier way to get the focus on the KDirOperator. It wouldn't be difficult to tie that to a certain key, but to communicate such key to the user would be a bit of a problem.
Created attachment 5635 [details] "give KDirOperator 'some' focus" NG I wasn't aware of the possibility to use the location field to change directories. That of course changes my vote. I agree that this can't be taken away. I do not think an access key for the KDirOperator would be a good idea - for the reason you mentioned and because it would be better to change the tab order in KFileDialog, e.g. 1 - shortcut bar, 2 - path combo, 3 - KDirOperator, 4 - Location field (ATM it is 2134). Then give focus to Location field (just as now) when KFileDialog appears. This way the KDirOperator is only 1 Tab or shift+tab away most of the time. Regarding my patch - I changed it to also make an exception if the focus is in the location field. That makes KFileDialog leave focus where it is provided that it's in a place which can be used to arbitrarily change directories (i.e. not the shortcut bar to the left). This should also meet your needs (as far as you expressed them). I did also look into changing the tab order, but the changes I tried were without any effect. I couldn't even mess it up ;-)
Moving from "kio/kfile" component to "kfile" product, helps sorting out duplicates.
I'm not sure there's a problem that needs solving here, to be honest. Changing focus like this doesn't seem desirable at all to support a niche use case.