In the filepicker dialog, if only one file is selected then in the file name line edit only selects the filename, without the extension
Details
- Reviewers
ngraham rkflx elvisangelaccio - Group Reviewers
Frameworks VDG - Maniphest Tasks
- T8552: Polish Open/Save dialogs
- Commits
- R241:6f15b9de84e4: Don't select file extension
Diff Detail
- Repository
- R241 KIO
- Branch
- select_filename_only (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage
Nice! But I notice that even though the correct part of the text is selected, the field doesn't actually receive focus.
Why don't we do it here, since it's more related--or even in a separate patch, since now that I test without the patch, it seems that it's actually an unrelated pre-existing bug.
There will be some problems with files that have multiple extensions, for example .tar.gz or .tar.bz
We could create a list of the most common multiextension filetypes, but I only know these two and Google isn't helpful.
Can some of you help me out here?
Should I even add such a list?
Let's only enable this behavior for the Save dialogs. For the Open dialogs, it seems sensible that you'd actually want the whole text selected (but not focused, see D12545), so that you can easily replace the whole thing if you want to file a file by name. Having the filename extension unselected would make it more difficult to do that, since you'd likely need to remove the extension manually.
Here's how this was recently done for Gwenview, if it helps: https://cgit.kde.org/gwenview.git/commit/?id=e85f4b589b93a5648b0150dca435018cd2fbae02
const QMimeDatabase db; const QString extension = db.suffixForFileName(filename); int selectionLength = filename.length(); if (extension.length() > 0) { // The filename contains an extension. Assure that only the filename // gets selected. selectionLength -= extension.length() + 1; } d->mFilename->setSelection(0, selectionLength);
Turns out this was already implemented before, but was not currently utilized.
These 3000+ lines files are hard to overview...
I removed these checks: && !locationEdit->isVisible()
I assume at one point the filename line edit was once set to hide/show on demand.
Nice. Looks like this does what it's supposed to for open and save, in both single and double-click mode. Tested with Kate, Spectacle, and Gwenview.
Thanks for the patch. Pondered over the code, but could not find anything wrong.
Beineri originally implemented this in 0134fb3a5e50, apparently. However, I don't understand why the check has a !. How could this ever work? At least in the latest KDE3 it is already broken.
Given that this is fixing a fairly straightforward bug, I feel pretty confident about this patch. Frameworks people: any objections, or shall we land this tomorrow?
src/filewidgets/kfilewidget.cpp | ||
---|---|---|
1304 | This comment makes little sense to me. Since it was part of the same commit spotted by @rkflx (0134fb3a5e50), I'd just remove it. | |
1344 | Same for this comment. |