Use " " to detect if there is multiple files and split filenames allowing them to contain ".
BUG: 185433
FIXED-IN: 5.65
ngraham | |
dfaure |
Frameworks |
Use " " to detect if there is multiple files and split filenames allowing them to contain ".
BUG: 185433
FIXED-IN: 5.65
ctest
No Linters Available |
No Unit Test Coverage |
Buildable 19244 | |
Build 19262: arc lint + arc unit |
This isn't working for me. When I create a file named "foobar".txt, the file dialog is still unable to open it, saying:
The file "/home/nate/Desktop/Foobar" could not be found
tests/kfilewidgettest_saving_gui.cpp | ||
---|---|---|
31 ↗ | (On Diff #70499) | These changes seem unrelated |
That's precisely the unit test included, it works for.
I think the app you tested with did not use your compiled kio because of kdeinit. You can use the included or recompile and use gwenview as it does not use kdeinit, you can also restart kdeinit before launching the app you want to test with :
$ kdeinit5 kdeinit5: Shutting down running client.
Restarting kdeinit is only needed when making changes that affect kioslaves.
Here it's just about a widget, all you need is to start the application from a terminal.
Thanks Méven. I can confirm that it works in Gwenview with no other changes. I have to re-compile Kolourpaint, but then it works from there too. Odd.
I think this needs more work, we lost some tolerance here, AFAICS.
src/filewidgets/kfilewidget.cpp | ||
---|---|---|
1751–1754 | What if I had "file1.txt" "file2.txt" and I manually edit that to remove the second file, ending up with just "file1.txt"? The double-quotes will no longer be removed, because of this modified condition. | |
1770–1772 | Isn't there a " at this position, always? Well, I guess we can keep an initial indexOf (outside the loop) in case there's a leading space (because a user manually removed the first file). So this needs additional unittests for leading space, trailing space, single-quoted-file .... and I wonder if we are OK with no longer supporting two spaces (e.g. because the user manually removed some intermediate file in the list). The separator is in fact " +" in regexp syntax, then? | |
1772 | this could move to after the if() block on the next line. | |
1780 | Isn't the last character a double-quote (in the normal case)? Don't we want to stop just before it, to avoid grabbing it? Of course this opens the question of what to do if the last character is NOT a double-quote, but |