| Summary: | Folder I'm currently in not restored when selecting "Open file" with remote protocol | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | rgpublic |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | ahartmetz, alexandre.sidorenko, bugs5.kde.org, diese-addy, emrecio, herve, jakobsg, kare.sars, kfunk, nx.devnull, sgh |
| Priority: | NOR | ||
| Version: | 5.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
rgpublic
2015-03-17 11:00:00 UTC
This still works with gwenview, but gwenview uses KFileDialog. I wrote a small app to test this. QFileDialog does not work with "sftp:/" or "remote:/", even though it's using the native dialog. Here's the problem: https://github.com/qtproject/qtbase/blob/v5.4.1/src/widgets/dialogs/qfiledialog.cpp#L2203 QUrl::fromLocalFile(dir) mangles sftp urls. You should use getOpenFileUrls instead of getOpenFileNames. This at least passes the url correctly to kdeplatformfiledialoghelper, but it still doesn't work. Sorry, Kate and Kwrite do use "getOpenFileUrls" for opening files, so it looks like the bug is in kdeplatformfiledialoghelper. Any update on when this might be fixed? BTW: What I find really amazing is that no one else seems to be complaining about this bug? Doesn't it occur on all distros? What am I doing differently? How does anyone else live with navigating 10 folders deep again and again for every single file they open? For me, Kate has become totally unusable due to this. I'm really puzzled that no one seems to bother... Most people probably only use local files, where it is not a problem. Are you able to use sshfs to mount the remote folder until it is fixed? Ah, ok. That might explain it. SSHFS is unfortunately as slow as a Galapagos turtle on tranqulizer. And the fact that I need to open files on lots of different servers with different network protocols doesn't help either. Oh, well. The great thing about Kate and KDE in general was always the network transparency. I'm currently using a different editor as a workaround which at least has some protocols built-in - nevertheless I miss Kate a lot - that's why I was asking if there is any progress on this. Thanks anyway, I'll wait patiently... *** Bug 346721 has been marked as a duplicate of this bug. *** This looks like a bug in either frameworksintegration, Qt or KIO I have not figured out which one yet. At some point the initial directory is overwritten.. These two don't work:
QFileDialog::getOpenFileUrls(this, "Open File", QUrl("sftp://user@example.org:22/home/user/"));
QFileDialog::getOpenFileUrls(this, "Open File", QUrl("remote:/"));
This works:
KFileDialog dialog(QUrl("sftp://user@example.org:22/home/user/"), "", this);
dialog.exec();
I've tried to debug QFileDialog, it looks like it initially sets the url, and I couldn't figure out where it gets overridden.
I'm suspecting that the problem might be related to: void QFileDialogPrivate::helperPrepareShow(QPlatformDialogHelper *) In this function we have a call to options->setInitialDirectory(), but I can not confirm that this is the problem yet, and I do not know yet what the proper solution would be in that case. Same problem here, under KDE4 everything worked fine, with KF5, when I go to open a file it takes me to my home directory instead of whatever sftp:// directory I was at, while I have an open sftp:// file. This should be fixed in newer versions of Qt and Frameworks (I think it was fixed in Qt 5.5 and a workaround in KF5 5.13) So, in their fixing it, they kinda broke it. So now when I have a file open via sftp, if I go to File -> Open, it attempts to open the actual full path/filename instead of the dirname. Reproduce: 1) open a file via sftp (sftp://foo.example.com/home/smithj/myfile.txt) 2) edit the file and save it 3) goto file -> open 4) error dialog comes up: The file or folder sftp://foo.example.com/home/smithj/myfile.txt does not exist. It's trying to go to that directory, but it's actually the file you have open instead. (when you click OK in the dialog box, in the directory line edit there's the full path/filename instead of just the path. In the above example it should be sftp://foo.example.com/home/smithj.) Should I open a new bug? JFTR, you're not alone. Debian recently updated Kate in unstable, and this is beyond the first things I noticed. Now I'm waiting for them to update to a version where this bug is fixed. In the meantime, I found that having two unnamed files open helps: 1. Open some remote file. 2. Hit ^o. Be presented a file open dialog located in ~. Close the dialog in frustration. 3. Hit ^n ^n. 4. Select the remote file in the documents tree. (I haven't tried the tabs.) 5. Select one of the unnamed files (doesn't seem to matter which one). 6. Hit ^o. The open file dialog should now try to browse the remote file as a directory (see https://bugs.kde.org/show_bug.cgi?id=352490), which is more closely to what we actually want. Works at least for Kate 15.08.0. Michael *** Bug 353794 has been marked as a duplicate of this bug. *** Funny thing about this bug is that "Save as..." seems to work. I also badly need "open..." to work but for now I have found a work-around just be careful: Pres "Save as..." to open the correct folder then drag the file you need to open to the main kate window. / JAkob Regarding the wrong path in open dialog, see bug 352490. |