Summary: | getsavefilename broken due to port to QFileDialog | ||
---|---|---|---|
Product: | [Applications] kdialog | Reporter: | Kai Uwe Broulik <kde> |
Component: | general | Assignee: | David Faure <faure> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | ahxcker, akontsevich, anomaly256, bugseforuns, chgonzalezg, simonandric5 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/kdialog/e9a26eb0d11d9edea7e4bdb585ede494310b9be0 | Version Fixed In: | |
Attachments: | Kdialog save as filter: unknown |
Description
Kai Uwe Broulik
2017-06-23 08:49:27 UTC
Wow that was fast ;) What do you call "correct" ? If application/octet-stream is the first mimetype, then it's selected as the first mimetype, I'm not sure what's incorrect there. Even if I save an html page which, from what I can tell only sends along text/html, I get "HTML document" as first entry and then an empty mimetype as second. In all cases it never pre-fills the file name, nor does it deduce the save location, ie. if it says --getsavefilename ~/foo/bar it used to open in ~/foo and pre-fill "bar" as file name. It no longer does that. And then if it pre-filled "foo.png" it would (should) know that it's "PNG image" I want and not application/octet-stream. Git commit 04706f321c3fb3660d9a1a8ec960229ea7ab11f9 by David Faure. Committed on 23/06/2017 at 21:03. Pushed by dfaure into branch 'Applications/17.04'. Trim filter string to be a bit tolerant and avoid empty mimetype entries Testcase: kdialog --getsavefilename . "text/html " M +1 -1 src/kdialog.cpp https://commits.kde.org/kdialog/04706f321c3fb3660d9a1a8ec960229ea7ab11f9 Git commit e9a26eb0d11d9edea7e4bdb585ede494310b9be0 by David Faure. Committed on 23/06/2017 at 21:41. Pushed by dfaure into branch 'Applications/17.04'. When startDir is a file, preselect it. Works fine for local files, but not for remote dirs, unless we use StatJob. M +32 -3 src/kdialog.cpp https://commits.kde.org/kdialog/e9a26eb0d11d9edea7e4bdb585ede494310b9be0 I was wondering about using QFileDialog::selectUrl rather than QFileDialog::setDirectoryUrl, but the argument is documented as [startDir], it was never supposed to be a preselected filename.... But OK, fixed, at least for local files. When I try to save an image now, it defaults to ".bin" extension for that file, instead of "webP" or "jpeg" despite the fact that chrome suggests .webp or .jpg extension. Chrome's source code has the following code: // Add the *.* filter, but only if we have added other filters (otherwise it // is implied). if (file_types_.include_all_files && !file_types_.extensions.empty()) filter_set.insert("application/octet-stream"); // Create the final output string. filter_string.clear(); for (std::set<std::string>::iterator it = filter_set.begin(); it != filter_set.end(); ++it) { filter_string.append(*it + " "); } So they deliberately add it as "All files" filter. With QFileDialog I get a ComboBox with "Unknown" (selected) and "JPEG image", before the port I got an editable ComboBox with just JPEG image in it. It doesn't always have an "Unknown", though, for text/html Chrome doesn't add application/octet-stream for some reason. Any particular reason this went into 17.04 bugfix branch and not master as file dialog stuff tends to break severly whenever someone touches it :/ getopenfilename also seems to be borked, when I try to upload a patch to Phab, while it gets the name in the file input form, uploading just fails. I don't see a difference in output from getopenfilename, however. (Also, dialog size restoration is broken) So the "unknown" (as I get with plasma-integration enabled) is expected. The *.bin can be a bit surprising, I agree --> https://bugs.freedesktop.org/show_bug.cgi?id=101667 What's the kdialog command that's broken, for your last comment? With the Qt or the KDE implementation? Kai, please check comment #8 and review the current state of the 17.04 branch. Does it still have regressions? I tried it with master. When I try to upload a Diff to Phabricator, Chrome just uploads forever. The commandline of the kdialog call was: kdialog --attach=109051905 --title="Datei öffnen" --getopenfilename /home/broulik/Projekte/kf5/plasma-workspace/../plasma-desktop I don't se anything suspicious with it besides the fact that it does not resolve the ../ path and shows that in the address bar. Also it no longer remembers the dialog's size (the QFileDialog is *not* the actual window it opens. The same reason I cannot make QML dialogs modal to it since I cannot access the underlying platform helper window) Created attachment 106689 [details]
Kdialog save as filter: unknown
Same problem here.
I find
Associations -> applications -> octet-stream
changed description's will effect kdialog filter:unkown
I don't know if this is useful or not!
Hi, any workaround for this? I see it's marked as 'resolved fixed' but I seem to be hitting it still in 17.08.2 Actually, I suspect I've only /started/ hitting it since my system upgraded from 17.04 to 17.08 of kdialog Bug still exists in latest KDE when downloading file in FF or Chromium. Why you've marked it as resolved?! I get .bin extension for all files instead of jpg, mp3, pdf, etc. report about the regression related here https://bugs.kde.org/show_bug.cgi?id=382437 Another bug here: if I download and save some file to directory named ../C#/ or ../C#/../.. it renamed to C and stored in parent ../C#/ directory. |