In the filepicker dialog when an item is selected move the focus to the filename line edit widget.
This already worked for users of "single click" in the Save dialog, and is now added for "double click" too.
Details
Details
- Reviewers
ngraham rkflx - Group Reviewers
Frameworks VDG - Maniphest Tasks
- T8552: Polish Open/Save dialogs
- change mouse settings to "double click"
- open the filepicker dialog
- select a file or directory
- focus is on the filename line edit and you can edit the text
- make sure keyboard navigation still works
Diff Detail
Diff Detail
- Repository
- R241 KIO
- Branch
- focus_lineedit (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage
Comment Actions
This is clearly what the code was trying to do, based on inline comments: https://cgit.kde.org/kio.git/tree/src/filewidgets/kfilewidget.cpp#n1176
However, are we sure this is the right fix? This will have the effect of adding the select-text-when-clicked behavior to the Open dialogs too, which does not seem to have been intended and which I don't think is helpful as it is for the Save dialogs. Perhaps we should change the locationEdit->setFocus(); to locationEdit->lineEdit()->setFocus(); on line 1179 instead.
Comment Actions
Hm, this breaks selecting files and even navigating directories with the keyboard (e.g. via the arrow keys), and as such cannot possibly be something we want.
I could imagine a different spin here: ⇥ should switch focus from the item view to the name line edit, which it currently does not. (And as the dialog starts with focus on the name line edit, ⇧+⇥ should switch focus immediately to the item view.)
Probably needs proper tabstop ordering.
From observing the behaviour, to me this seems to affect the save dialog, and only upon clicking on a file. When navigating via the keyboard and thus merely selecting a file, this does not seem to be called. IOW, this part of the code seems fine to me.
Comment Actions
Good point @rkflx, we definitely don't want to break keyboard navigation. We want this behavior only when clicking, and only for the save dialog.
Comment Actions
Yeah, but not sure I understand. Isn't this exactly the behaviour we currently have, without the patch?
Comment Actions
No, it doesn't actually work. Turn on double-click, open a save dialog, click once on a file, and start typing. The typing is inrerpreted as type-ahead navigation instead of replacing the filename.
I can reproduce this behavior with git master as well as Frameworks 5.45.
Comment Actions
Aha! This is what I'm missing. It should be mentioned in the summary if non-default settings are used :D
Comment Actions
This patch really breaks keyboard navigation.
I'm thinking about abandoning this revision in favor of proper tab ordering instead.
@ngraham are you ok with this?
Comment Actions
Proper tab ordering is important too. But IMHO this feature is worth keeping. When you've clicked on an existing file, the next thing you're going to do with it is either overwrite it, or slightly change the name of the file you're saving. Both of those use cases benefit from the focus automatically moving to the name field.
Comment Actions
As Nate already said, tabstop ordering would also be good to have. But given that the feature already works for single-click users, maybe you could make it work for double-click users too (i.e. for the first "selection" click) instead of abandoning? After all, in D12538 we are doing something similar (add a double-click feature for single-click users).
Comment Actions
@ngraham I'm sorry, but because of my new job I don't have much free time left so I can't actively develop anymore. I'd really like if someone took over this patch.