[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Provide symbolic link destination as additional
From:       "Frank Reininghaus" <frank78ac () googlemail ! com>
Date:       2010-05-09 11:29:16
Message-ID: 20100509112916.16177.27999 () localhost
[Download RAW message or body]



> On 2010-05-08 22:36:37, Peter Penz wrote:
> > Thanks Frank! From my point of view there are no objections to commit the patch \
> > on Monday (including Sebastian's patch from http://reviewboard.kde.org/r/3354). I \
> > hope that Fredrik can give an official "Ship It"...
> 
> Fredrik Höglund wrote:
> No objections from me as far as the code is concerned, but I'm wondering if what \
> this and Sebastian's patch adds isn't the same thing from the user's point of view; \
> the real location of the file. If so, should they share the same enum value? The \
> delegate could show the link destination if the file is a link, and the local URL \
> if not.

I think there are two reasons why it might make sense to keep "local path or URL" and \
"link destination" separate:

1. Sebastian's goal is to provide the real location of search results. If one of \
these results is a link, that would be the location of the link, and not the file it \
points to.

2. The KDE 3 functionality that many users miss is a "Link Destination" column that \
displays the link destination for symbolic links, but is empty for all other files. \
That makes it possible to recognise links very easily. If we display the path for \
non-link files in that column, this advantage would be lost.

But I'm not 100% sure what the best approach is - I've added Sebastian to this review \
request, maybe he has an opinion on this...


- Frank


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3912/#review5533
-----------------------------------------------------------


On 2010-05-09 11:26:17, Frank Reininghaus wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3912/
> -----------------------------------------------------------
> 
> (Updated 2010-05-09 11:26:17)
> 
> 
> Review request for kdelibs, Peter Penz, Sebastian Trueg, and Fredrik Höglund.
> 
> 
> Summary
> -------
> 
> I propose to provide the destination of a symbolic link as additional information \
> in KFileItemDelegate. This will enable us to provide that as a column in Dolphin's \
> and Konqueror's Details View, which has been requested a couple of times (note that \
> KDE 3 had that feature). 
> Like Sebastian who filed the related request http://reviewboard.kde.org/r/3354/, I \
> think that this information may be useful outside Dolphin and should therefore be \
> provided in KFileItemDelegate. Additionally, Dolphin currently stores the \
> additional columns which are enabled in a KFileItemDelegate::InformationList, which \
> means that not adding this information in KFID, but only in Dolphin itself would \
> require a total rewrite of the code that stores the additional columns. 
> Any feedback is appreciated. If nobody (in particular Fredrik) objects, I'd like to \
> commit this on Monday to make sure that we can get this feature into 4.5. I could \
> include Sebastian's patch in my commit if there is agreement that both additions to \
> KFID are desirable. 
> 
> Diffs
> -----
> 
> /trunk/KDE/kdelibs/kio/kio/kfileitemdelegate.h 1123638 
> /trunk/KDE/kdelibs/kio/kio/kfileitemdelegate.cpp 1123638 
> 
> Diff: http://reviewboard.kde.org/r/3912/diff
> 
> 
> Testing
> -------
> 
> I've got a patch for Dolphin that makes use of this in the Details View - works as \
> expected for me. 
> 
> Thanks,
> 
> Frank
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]