https://bugs.kde.org/show_bug.cgi?id=456198
--- Comment #22 from Méven Car <meve...@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 > alanjpresc...@gmail.com > > > On Mon, 22 Jul 2024 at 17:21, Méven Car <bugzilla_nore...@kde.org> wrote: > > > https://bugs.kde.org/show_bug.cgi?id=456198 > > > > --- Comment #20 from Méven Car <meve...@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 watching all bug changes.
