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.
ngraham | |
rkflx |
Frameworks | |
VDG |
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.
No Linters Available |
No Unit Test Coverage |
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.
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.
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.
Yeah, but not sure I understand. Isn't this exactly the behaviour we currently have, without the patch?
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.
Aha! This is what I'm missing. It should be mentioned in the summary if non-default settings are used :D
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?
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.
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).
@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.