301757 2012-06-12 17:59:43 +0000 Can no longer open a file using the address bar 2012-06-20 18:57:48 +0000 1 1 2 Applications dolphin general 2.0.95 unspecified Linux RESOLVED FIXED regression NOR normal --- 1 kde peter.penz19 http://commits.kde.org/kde-baseapps/3f5f69ad267e0a4df5e0b6377f63dfd2992ead9c 4.9.0 0 oldest_to_newest 1265042 0 kde 2012-06-12 17:59:43 +0000 It always annoyed me that there was no auto-completion for files in the address bar but now I cannot even open a file if I enter its URL manually there anymore. It throws an error "/home/user/somefile.png is a file, a directory was expected." Reproducible: Always Steps to Reproduce: 1. Enter the URL to a file into Dolphin’s address bar 2. 3. Actual Results: An error claiming that this is not a folder but a file appears Expected Results: The respective file is opened in its associated application 1265097 1 peter.penz19 2012-06-12 19:18:29 +0000 Thanks for the report, thats a regression in comparison to 2.0. 1265338 2 peter.penz19 2012-06-13 12:41:09 +0000 Hm, I thought this will be a "5-liner-patch" but solving this in a clean and fast way (= without checking whether the changed URL represents a file on each directory change) requires some more investigations. I currently don't have the time for this, so I'm summarizing the observations here for the future (or in case if somebody else wants to provide a patch): In DolphinViewContainer::slotUrlNavigatorLocationChanged() there is no non-expensive way to check whether the entered line of the URL-navigator represents a file or directory. So one proposal would be: - Apply the entered line as URL to the DolphinView like done now - KFileItemModel will reply an error-message. Now instead of just forwarding the error-message, adjust KFileItemModelDirLister to emit a custom message in case if a file has been passed (see KJob::error()). - Let KFileItemModel forward this signal (directoryLoadingFailed()?) - Let DolphinView forward this signal - React on this message in DolphinViewContainer and do the expensive check whether it is a file. If this is the case, just do a KRun on it. A probably more generic approach would be to add an error-code to the errorMessage, so that the receiver can decide whether to show the error-message or react in a different way on it. Before starting this: In Dolphin 2.0 the file gets executed correctly without error-message (although the directory will still be changed which is not nice). I'm somehow surprised about this but did no check yet how this can happen - probably there is a way easier approach than my suggestion above. 1265341 3 peter.penz19 2012-06-13 12:55:38 +0000 OK, I could not resist to check why it works with 2.0 but not with 2.1 anymore. The root-cause is that for 2.1 the DolphinDirLister has been moved inside KFileItemModel as KFileItemModelDirLister. During this refactoring the following code has been removed: void DolphinDirLister::handleError(KIO::Job* job) { if (job->error() == KIO::ERR_IS_FILE) { emit urlIsFileError(url()); } else { const QString errorString = job->errorString(); if (errorString.isEmpty()) { emit errorMessage(i18nc("@info:status", "Unknown error.")); } else { emit errorMessage(errorString); } } } so the suggestion above is valid and had been somehow implemented already ;-) I'll take care to fix this during the next days and need to find some time. 1265349 4 peter.penz19 2012-06-13 13:18:45 +0000 Git commit 3f5f69ad267e0a4df5e0b6377f63dfd2992ead9c by Peter Penz. Committed on 13/06/2012 at 15:15. Pushed by ppenz into branch 'master'. Fix regression: Open file if entering it in the URL-navigator The regression has been introduced when hiding the DolphinDirLister inside KFileItemModel. Now the signal urlIsFileError() gets forwarded to the container again where the file will be opened. FIXED-IN: 4.9.0 M +7 -0 dolphin/src/dolphinviewcontainer.cpp M +6 -0 dolphin/src/dolphinviewcontainer.h M +1 -0 dolphin/src/kitemviews/kfileitemmodel.cpp M +6 -0 dolphin/src/kitemviews/kfileitemmodel.h M +8 -4 dolphin/src/kitemviews/private/kfileitemmodeldirlister.cpp M +6 -0 dolphin/src/kitemviews/private/kfileitemmodeldirlister.h M +1 -0 dolphin/src/views/dolphinview.cpp M +6 -0 dolphin/src/views/dolphinview.h http://commits.kde.org/kde-baseapps/3f5f69ad267e0a4df5e0b6377f63dfd2992ead9c 1265404 5 kde 2012-06-13 16:00:07 +0000 Umm, thanks for the explanation! This means, now I can open a file directly through the address bar but I will not end up with an empty folder like before then? Highly appreciated! :-) 1265446 6 peter.penz19 2012-06-13 17:25:52 +0000 Sadly the empty folder will still be there :-( I tried to go back to the previous folder but this results in flickering. Everything is solveable of course but I doubt in this case it is worth the added internal complexity + efforts. I'm interested: May I ask whats your "typical" usecase for opening a file this way? 1265452 7 kde 2012-06-13 17:43:52 +0000 Okay, at least now I can open files again :) I also don’t think it is worh the effort. Usually it’s laziness. Normally I use the filter bar, filter the files and then open the one(s) I need. But especially when I want to open dot files, I don’t want to first show hidden files (Alt+Period) then search for my file (such as .directory or .htaccess) and then hide those files again as it "pollutes" my view. So, as you can see, it is not that of a typical usecase, so the way it now is (it never disturbed me in the past years, so why should it now) is fine. 1268175 8 kde 2012-06-20 16:18:07 +0000 Concerning that empty folder: So, it is also not possible to prevent an empty folder from showing if the *folder* you are navigating to does not exist? 1268216 9 peter.penz19 2012-06-20 18:57:48 +0000 Not in an easy way: Dolphin will only get informed that the folder does not exist asynchronously after passing the URL to the KDirLister which uses the corresponding I/O-slave. When getting the message Dolphin already cleared the content of the view. The check could be done before quite easy for local files from a coding point of view, but this would be an unnecessary performance overhead that I'd like to prevent.