[frameworks-kio] [Bug 456198] Targets of relative symbolic links are resolved incorrectly in the status bar

[Méven Car]

https://bugs.kde.org/show_bug.cgi?id=456198

--- Comment #22 from Méven Car <meven29 at gmail.com> ---
(In reply to Alan Prescott from comment #21)
> Created attachment 171901 [details]
> attachment-3292567-0.html
> 
> I would have thought that it should reflect the output from `ls -l`
> 
> Alan Prescott
> alanjprescott at gmail.com
> 
> 
> On Mon, 22 Jul 2024 at 17:21, Méven Car <bugzilla_noreply at kde.org> wrote:
> 
> > https://bugs.kde.org/show_bug.cgi?id=456198
> >
> > --- Comment #20 from Méven Car <meven29 at gmail.com> ---
> > (In reply to Alan Prescott from comment #18)
> > > You are correct in that the target is the same whether the symlink is
> > > absolute or relative  but, personally, I'd have thought that the path
> > > displayed would be the same as if I'd typed `ls -l`.
> > > If the link always shows as an absolute path then we're missing the
> > chance
> > > to provider the user with available information which (s)he will have to
> > go
> > > to a terminal window to find out.
> >
> > This isn't really practical: if you have expanded folders, with a pointing
> > being a relative symlink, how should the path be resolved relative to ?
> > The root expanded folder ? The folder containing the the file ?
> >
> > For instance
> > /a/afile
> > /b/afile -> ../a/afile
> >
> > And with / opened with folder opened what should the status bar show when
> > hovering over /b/afile ?
> > The only systematic clear answer is absolute path.
> > We can still tilde collapse it though.
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.

I have remade my patch, it is now compliant with what you expect.
This still makes sense to show the relative path, it will be relative to the
file location as with `ls -/`.

 https://invent.kde.org/frameworks/kio/-/merge_requests/1664

-- 
You are receiving this mail because:
You are on the CC list for the bug.