Bug 301757 - Can no longer open a file using the address bar
Summary: Can no longer open a file using the address bar
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 2.0.95
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-06-12 17:59 UTC by Kai Uwe Broulik
Modified: 2012-06-20 18:57 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.9.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Uwe Broulik 2012-06-12 17:59:43 UTC
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
Comment 1 Peter Penz 2012-06-12 19:18:29 UTC
Thanks for the report, thats a regression in comparison to 2.0.
Comment 2 Peter Penz 2012-06-13 12:41:09 UTC
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.
Comment 3 Peter Penz 2012-06-13 12:55:38 UTC
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.
Comment 4 Peter Penz 2012-06-13 13:18:45 UTC
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
Comment 5 Kai Uwe Broulik 2012-06-13 16:00:07 UTC
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! :-)
Comment 6 Peter Penz 2012-06-13 17:25:52 UTC
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?
Comment 7 Kai Uwe Broulik 2012-06-13 17:43:52 UTC
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.
Comment 8 Kai Uwe Broulik 2012-06-20 16:18:07 UTC
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?
Comment 9 Peter Penz 2012-06-20 18:57:48 UTC
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.