Summary: | (patch) KFileDialog: give focus to KDirOperator at directory change | ||
---|---|---|---|
Product: | [Applications] kfile | Reporter: | Andreas Leuner <almighty> |
Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
Status: | RESOLVED INTENTIONAL | ||
Severity: | wishlist | CC: | bastian, nate |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
give KDirOperator 'some' focus
"give KDirOperator 'some' focus" NG |
Description
Andreas Leuner
2003-12-10 17:11:07 UTC
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. |