3.5 branch kfmclient/KRun problem with local HTML files and anchors

[David Faure]

On Tuesday 15 August 2006 21:56, Kevin Krammer wrote:
> On Tuesday 15 August 2006 21:45, David Faure wrote:
> > On Sunday 13 August 2006 09:45, Stephan Kulow wrote:
> > > Am Sonntag, 13. August 2006 01:50 schrieb Kevin Krammer:
> > > > A Portland xdg-utils tester reported a problem when launching a file
> > > > URL with anchor: https://bugs.freedesktop.org/show_bug.cgi?id=7863
> > > >
> > > > Summary:
> > > > kfmclient exec http://host/path#anchor works
> > > > kfmclient exec file:/path#anchor does not work (anchor gets lost)
> > > >
> > > > I tracked it down to
> > > > krun.cpp method KRunMX2::subst
> > > >
> > > > educated guess:
> > > >
> > > > ret << (url.isLocalFile() ? url.path() : url.url());
> > > >
> > > > strips the anchor since isLocalFile() returns true
> > > >
> > > > Is this a bug or intentional?
> > >
> > > I think this is an invalid overoptimization. If a .desktop file has %u it
> > > can handle URLs and shouldn't see paths. But the line in question is
> > > pretty old. I guess removing this check would work still.
> >
> > IIRC this was because "a path looks nicer than a url".
> >
> > How about using ret << url.pathOrURL() instead? It has exactly the right
> > logic, i.e. to only return a path if it's a local file, with no ref and no
> > query in the url.
> 
> Works like expected. Though what is the use case of beautifying the parameter 
> when the launched application has to be able to deal with URIs anyway?

Actually, IIRC there are apps which don't handle file:/// URIs. Or file:/.
IIRC the problem was with xmms, but before we switched to file:///.
In any case, it sounds like much less trouble to send paths to apps instead of file uris,
because of those possible incompatibilities.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).