Version: (using KDE KDE 3.1.1) Installed from: Compiled From Sources OS: Linux When you change directory in Konsole using "cd" and the directory (say "/home/user/link") is acually a link to "/home/user/target", PWD will say you are in /home/user/link. When you change directory in Konqueror by clicking on it and the directory (say "/home/user/link") is acually a link to "/home/user/target", the address bar will say you are in /home/user/target. This is inconsistent and confusing to unexperienced Linux users. As a system administrator, I want to be able to create links to /mnt/diskxxx for example and I want these links to be transparent to the users. Users tend to get confused if they get redirected to /mnt/. They think they're in the wrong spot, as they have left their home directory.
Agreed. I've actually seen this confuse some people.
On Tuesday 07 March 2006 20:46, Andras Mantia wrote: > Hi, > > I expect this to be a controversial patch, but it is needed to achieve > consistency within Konqueror itself. The problem is described in > http://bugs.kde.org/123230 . The reason why I changed here and not in > the sidebar is because it would be still inconsistent, as the user > could enter the directory by typing the path in the location bar. > I have no idea why the symlink resolving was needed, maybe it was > useful when running applications, but KFileItem::run anyway uses the > destination, not the link. Well if you follow the comment and read KFileItem::run you can see that: // When clicking on a link to e.g. $HOME from the desktop, we want to open $HOME Imagine you have a link to your home on the desktop called "MyHome", when clicking on it you don't want to see "/home/user/Desktop/MyHome/" in konqueror, but /home/user. So how do we solve this? In one case a symlink is used to hide the actual location of a directory (/mnt) and in the other case the actual location (home) *is* where we want to go, the symlink is just a convenient way to go there. Do we need a desktop-specific hack (making symlink-resolution happen only if the link is on the desktop), or does someone have a better idea?
*** Bug 123230 has been marked as a duplicate of this bug. ***
On Thursday 09 March 2006 12:08, David Faure wrote: > making symlink-resolution happen only if the link is on the desktop ... is done in the attached patches. Of course when going to ~/Desktop/ in konqueror, then clicking on a link to $HOME leads to /home/dfaure/Desktop/myhome, but I guess that's fine, it gives a consistent behavior in konqueror, and another one on the desktop (not the first time...) Created an attachment (id=15024) [details] kfileitem.cpp.diff Created an attachment (id=15025) [details] libkonq.diff
Just for the record post my answer here as well: > Well if you follow the comment and read KFileItem::run you can see > that: // When clicking on a link to e.g. $HOME from the desktop, we > want to open $HOME I read it but it wasn't clear. > Imagine you have a link to your home on the desktop called "MyHome", > when clicking on it you don't want to see > "/home/user/Desktop/MyHome/" in konqueror, but /home/user. Hm, I missed this issue. > So how do we solve this? In one case a symlink is used to hide the > actual location of a directory (/mnt) and in the other case the > actual location (home) *is* where we want to go, the symlink is just > a convenient way to go there. Do we need a desktop-specific hack > (making symlink-resolution happen only if the link is on the > desktop), or does someone have a better idea? The current behavior is very confusing for a normal user and as I wrote it is inconsistent as well. So unless there is abetter idea I support the desktop-specific hack. Andras
I would rather propose to only resolve symlinks that point to places inside $HOME. This way, other 'scary places' outside $HOME will always be hidden and appear to live inside $HOME. The user will never be taken outside $HOME.
I tested and like David's solution. From my point of view you can commit.
Dik: having a different behavior for links on the desktop makes sense to me (it's already the case for showing the Name field of .desktop files, etc.). Having a different behavior depending on the target of the symlink makes little sense though. If /opt is made a symlink to /mnt/something/ia64/opt, then for the same reasons as those described in this bug report, the user should only see /opt in Konqueror.
SVN commit 517437 by dfaure: Don't resolve links in konqueror, but still resolve them on the desktop. BUG: 63014 M +12 -1 kfileivi.cc M +0 -3 konq_dirpart.cc --- branches/KDE/3.5/kdebase/libkonq/kfileivi.cc #517436:517437 @@ -29,6 +29,7 @@ #include <kiconeffect.h> #include <kfileitem.h> #include <kdebug.h> +#include <krun.h> #undef Bool @@ -344,7 +345,17 @@ void KFileIVI::returnPressed() { - m_fileitem->run(); + if ( static_cast<KonqIconViewWidget*>(iconView())->isDesktop() ) { + KURL url = m_fileitem->url(); + // When clicking on a link to e.g. $HOME from the desktop, we want to open $HOME + // Symlink resolution must only happen on the desktop though (#63014) + if ( m_fileitem->isLink() && url.isLocalFile() ) + url = KURL( url, m_fileitem->linkDest() ); + + (void) new KRun( url, m_fileitem->mode(), m_fileitem->isLocalFile() ); + } else { + m_fileitem->run(); + } } --- branches/KDE/3.5/kdebase/libkonq/konq_dirpart.cc #517436:517437 @@ -318,9 +318,6 @@ args.serviceType = fileItem->mimetype(); args.trustedSource = true; - if ( fileItem->isLink() && fileItem->isLocalFile() ) // see KFileItem::run - url = KURL( url, KURL::encode_string( fileItem->linkDest() ) ); - if (KonqFMSettings::settings()->alwaysNewWin() && fileItem->isDir()) { //args.frameName = "_blank"; // open new window // We tried the other option, passing the path as framename so that
Ok, I'm fine with the changes.
You need to log in before you can comment on or make changes to this bug.
KDE Bug Tracking System
KDE Bug Tracking System 