Re: Review Request: Support for GRUB2 submenus
On Aug. 6, 2012, 6:26 a.m., Oswald Buddenhagen wrote:
ksmserver/shutdowndlg.cpp, line 488
http://git.reviewboard.kde.org/r/105563/diff/14/?file=76096#file76096line488
as you make assumptions about the list structure below anyway, you can
just make the menus a stack (though then you need a condition to track when
you need to pop items - but that's still shorter and more elegant than this
findMenu stuff, i think).
Konstantinos Smanis wrote:
I could be wrong but how is this gonna work with nested submenus?
submenu 'foo' {
menuentry 'bar' {
}
submenu 'baz' {
menuentry 'test' {
}
}
menuentry 'test2' {
}
}
You pop once to get foo from the stack, add bar to foo, then pop baz and
foo is gone; where will test2 go?
eh? foo stays on the stack till the end.
i think the algorithm is more or less like this:
while not nested into current menu
pop current menu
# you already have the following part
if submenu
push current menu
else
add entry
- Oswald
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105563/#review16926
---
On Aug. 5, 2012, 1:25 p.m., Konstantinos Smanis wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105563/
---
(Updated Aug. 5, 2012, 1:25 p.m.)
Review request for KDE Runtime and Oswald Buddenhagen.
Description
---
Recent versions of GRUB2 introduce submenus which allow for nesting levels to
appear (instead of the flat list in the past).
This patch consists of two parts: the parsing part in KDM (bootman.c) and
creating a menu structure from the parsed list in ksmserver (shutdowndlg.*)
The parsing part produces a list like this:
Gentoo GNU/Linux
Advanced options for Gentoo GNU/Linux
Advanced options for Gentoo GNU/LinuxGentoo GNU/Linux, with Linux 3.4.4
Advanced options for Gentoo GNU/LinuxGentoo GNU/Linux, with Linux 3.4.4
(recovery mode)
Windows 7 (loader) (on /dev/sda2)
?
which is then converted into the menu structure. These full identifiers can
be properly used with `grub2-reboot`.
More info about submenus: http://ubuntuforums.org/showthread.php?p=10720316
Also check the related bug.
The parsing part of the patch can be applied in the KDE/4.9 and master
branches as well (tested and working in KDE 4.8.95 and 4.9.x). ksmserver has
migrated to QML since then however, and the menu structure has to wait.
Currently it looks like this: http://i50.tinypic.com/96bw35.png
Related ML-discussion:
http://lists.kde.org/?l=kde-core-develm=134160279511422w=2
Update: There is a proper fix now for KDE/4.9 and master:
https://git.reviewboard.kde.org/r/105568/
This addresses bug 297209.
http://bugs.kde.org/show_bug.cgi?id=297209
Diffs
-
kdm/backend/bootman.c 8b834d2
kdm/backend/dm.h 13e7b45
kdm/backend/util.c 6cd93ef
ksmserver/shutdowndlg.h e5f0942
ksmserver/shutdowndlg.cpp a09a1a7
Diff: http://git.reviewboard.kde.org/r/105563/diff/
Testing
---
Works with the menu file produced in my system with `grub2-mkconfig`.
Also works with a custom menu file I made (as shown in the second screenshot).
Screenshots
---
Distribution's stock menu file
http://git.reviewboard.kde.org/r/105563/s/633/
A custom menu file for testing
http://git.reviewboard.kde.org/r/105563/s/634/
Thanks,
Konstantinos Smanis
Re: Review Request: Fix Warning messages when closing About popup
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105627/#review16965 --- Ship it! Heh, well it's not like KWidgetItemDelegate is maintained, clearly. No objection to the patch, even though it shows once again that KWidgetItemDelegate is a bit fragile This is the warning you get, right? kWarning() User of KWidgetItemDelegate should not delete widgets created by createItemWidgets!; Clearly that warning can't differenciate between developer is deleting my widgets and Qt is cleaning up everything. I wonder how similar things are done in Qt itself. I guess there's no warning, but rather proper handling of both cases. - David Faure On July 19, 2012, 10:23 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105627/ --- (Updated July 19, 2012, 10:23 p.m.) Review request for kdelibs, Frederik Gladhorn and David Faure. Description --- There is a too agressive check in KWidgetItemDelegateEventListener that complains about User of KWidgetItemDelegate should not delete widgets created by createItemWidgets! when closing an about dialog. I tried making it less agressive but since i could not, i'm just deleting things in a different order in the destruction of KAboutApplicationDialog so that the warning is not triggered and our users get angry This addresses bug 301628. http://bugs.kde.org/show_bug.cgi?id=301628 Diffs - kdeui/dialogs/kaboutapplicationdialog.cpp 2c98f74 Diff: http://git.reviewboard.kde.org/r/105627/diff/ Testing --- Dialog still works, valgrind doesn't complain, the warning is gone Thanks, Albert Astals Cid
Re: Review Request: Allow symlink creation for kio protocols that support it
On Aug. 3, 2012, 8:48 a.m., David Faure wrote: I'm not sure this makes sense. You drag-n-drop a symlink called link to a file called target from fish://myhost to your local $HOME, and you end up with a broken symlink, given that target is nowhere to be found? The logic of the test isn't about does the protocol support creating symlinks (kio_file certainly does), it's about whether it makes sense to copy a symlink as a symlink when copying it out of the original location (protocol+host+port+login). The now-lost bug 5601 was about going into an FTP folder that is full of symlinks (e.g. pointing to release tarballs), and (as a user) copying one of these to your HOME, in order to download the tarball. Ending up with just a symlink is kind of pointless. The exact same case could be made for FISH or NFS, the source protocol is rather irrelevant here. The real problem is what does the user really intend to do here (if you were copying the full hierarchy including the target files then you would probably want the symlinks to stay as symlinks...) Maybe the solution lies in offering more choices to the user, yet again... i.e. when dragging a symlink, offer copy target in the popupmenu, while copyNextFile() (which is also called when dragging entire directories) should copy symlinks as is... Lamarque Vieira Souza wrote: One of the uses for this is archiving a directory with symlinks, specially symlink to a directory. The user may not be interested in archiving the directory itself and currently kio creates an empty file everytime it copies a symlink to a directory (it treats symlinks to directory like symlinks to a file), so nothing is actually copied. David Faure wrote: Empty file? That sounds like a bug in the symlink() implementation of the destination kioslave, no? This code is supposed to create a symlink at the destination. If anything else happens, then that should be fixed, rather than skipping the creation of the symlink. Lamarque Vieira Souza wrote: It's not a bug in symlink() because it is never called by kdelibs when source and destination protocols are different. In that case if you try to copy a symlink to a directory kdelibs tries to copy the target as a file, which obviously does not work when the target is a directory. For example, try to copy ftp://ftp.kde.org/pub/kde/snapshots (a symlink to directory) to your home directory using Dolphin. It will failed with a message ftp://ftp.kde.org/pub/kde/snapshots is a folder, but a file was expected.. That happens because kdelibs is calling KIO::file_copy() instead of KIO::symlink() or CopyJobPrivate::createNextDir(). I see. This is not a bug in kdelibs, but in kio_ftp, because it cannot distinguish a symlink-to-a-file from a symlink-to-a-directory (this would require issuing multiple FTP commands, changing directory to the target and listing it). I'm pretty sure that if you try this with kio_sftp there is no such issue? - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105831/#review16813 --- On Aug. 2, 2012, 9:31 p.m., Lamarque Vieira Souza wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105831/ --- (Updated Aug. 2, 2012, 9:31 p.m.) Review request for kdelibs. Description --- Some kio protocols support creating symlinks but a change in kio/kio/copyjob.cpp hardcoded symlink creation to only when source and destination protocols are the same. That change was added to fix a problem with ftp protocol creating symlinks instead of copying files (there is a comment in the source code about that). I think instead of forcing source and destination use the same protocol we should test if the destination protocol supports creating symlinks (ftp protocol does not). That would allow kio's like fish and nfs create symlinks. I am also working on some other changes that could use this feature. Diffs - kio/kio/copyjob.cpp 8dde763 Diff: http://git.reviewboard.kde.org/r/105831/diff/ Testing --- Thanks, Lamarque Vieira Souza
Re: Review Request: Allow symlink creation for kio protocols that support it
On Aug. 3, 2012, 8:49 a.m., David Faure wrote: Actually we need to test both source and destination to check if their protocols support symlink creation. Haha, if we're copying a symlink, then obviously the source protocol supports symlinks, otherwise it wouldn't be there in the first place :-) Lamarque Vieira Souza wrote: I meant supports *creating* symlinks, not only *showing* symlinks. ftp kio protocol does not support creating symlinks according to its ftp.protocol file. David Faure wrote: So? If you're copying a symlink *from* FTP to the local harddrive, what should it matter, that kio_ftp cannot *create* symlinks? The symlink is there, it exists, so checking whether kio_ftp can create symlinks is totally irrelevant. Only the capability of the destination protocol matters, not the one of the source protocol. Lamarque Vieira Souza wrote: I am using that heuristics to avoid the symlink with ftp problem to come back (bug #5601). If I just test the destination protocol it will always create a symlink if the destination protocol is file. We could call KIO::symlink() if both source and destination are local, do you know a way to detect that besides checking if QUrl::host() is empty? You realize how wrong that heuristic is, right? It's testing for something completely unrelated to the operation at hand, just to exclude FTP, in order to work around a problem, which isn't even specific to FTP (the issue that we sometimes want to copy symlinks as is, and sometimes to copy their target). You can detect pseudo-local protocols using KProtocolInfo::protocolClass(url.protocol()) == :local, but this sounds like a hack too. Don't you agree that the real fix would be to copy source URLs (i.e. objects actually dragged by the user) by following symlinks, and to copy symlinks as symlinks otherwise (when we encounter one inside a directory that we're copying)? This doesn't help with the issue that FTP can't distinguish symlinks to files and to directories, but that's orthogonal, let's use fish or sftp as examples instead, if they do distinguish these correctly. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105831/#review16814 --- On Aug. 2, 2012, 9:31 p.m., Lamarque Vieira Souza wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105831/ --- (Updated Aug. 2, 2012, 9:31 p.m.) Review request for kdelibs. Description --- Some kio protocols support creating symlinks but a change in kio/kio/copyjob.cpp hardcoded symlink creation to only when source and destination protocols are the same. That change was added to fix a problem with ftp protocol creating symlinks instead of copying files (there is a comment in the source code about that). I think instead of forcing source and destination use the same protocol we should test if the destination protocol supports creating symlinks (ftp protocol does not). That would allow kio's like fish and nfs create symlinks. I am also working on some other changes that could use this feature. Diffs - kio/kio/copyjob.cpp 8dde763 Diff: http://git.reviewboard.kde.org/r/105831/diff/ Testing --- Thanks, Lamarque Vieira Souza
Review Request: Fix hang in kcm_useraccount
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105895/ --- Review request for KDE Base Apps. Description --- When changing the user's full name, chfn may not necessarily produce any output. Since readLine blocks, the kcm may hang. This change checks if chfn exited without output, and if so, use that exit status. This addresses bug 156396. http://bugs.kde.org/show_bug.cgi?id=156396 Diffs - kdepasswd/kcm/chfnprocess.cpp 9f75d4aa75b41acec84e7798c789d4226ca3fab9 Diff: http://git.reviewboard.kde.org/r/105895/diff/ Testing --- On a PAM-enabled system: * Full name changed successfully when permitted by login.defs * Error presented and no change processed with prohibited by login.defs Thanks, Michael Palimaka
Re: Review Request: Fix hang in kcm_useraccount
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105895/#review16985 --- kdepasswd/kcm/chfnprocess.cpp http://git.reviewboard.kde.org/r/105895/#comment13338 Why unread the line if you read it again just 3 lines below? Why not just put the readline() below in an else clause? - Rolf Eike Beer On Aug. 6, 2012, 1:20 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105895/ --- (Updated Aug. 6, 2012, 1:20 p.m.) Review request for KDE Base Apps. Description --- When changing the user's full name, chfn may not necessarily produce any output. Since readLine blocks, the kcm may hang. This change checks if chfn exited without output, and if so, use that exit status. This addresses bug 156396. http://bugs.kde.org/show_bug.cgi?id=156396 Diffs - kdepasswd/kcm/chfnprocess.cpp 9f75d4aa75b41acec84e7798c789d4226ca3fab9 Diff: http://git.reviewboard.kde.org/r/105895/diff/ Testing --- On a PAM-enabled system: * Full name changed successfully when permitted by login.defs * Error presented and no change processed with prohibited by login.defs Thanks, Michael Palimaka
Re: Review Request: Fix hang in kcm_useraccount
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105895/#review16989 --- How does this play with https://git.reviewboard.kde.org/r/104439 ? - Raphael Kubo da Costa On Aug. 6, 2012, 5:03 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105895/ --- (Updated Aug. 6, 2012, 5:03 p.m.) Review request for KDE Base Apps. Description --- When changing the user's full name, chfn may not necessarily produce any output. Since readLine blocks, the kcm may hang. This change checks if chfn exited without output, and if so, use that exit status. This addresses bug 156396. http://bugs.kde.org/show_bug.cgi?id=156396 Diffs - kdepasswd/kcm/chfnprocess.cpp 9f75d4aa75b41acec84e7798c789d4226ca3fab9 Diff: http://git.reviewboard.kde.org/r/105895/diff/ Testing --- On a PAM-enabled system: * Full name changed successfully when permitted by login.defs * Error presented and no change processed with prohibited by login.defs Thanks, Michael Palimaka
Re: Review Request: Support for GRUB2 submenus
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105563/ --- (Updated Aug. 6, 2012, 6:29 p.m.) Review request for KDE Runtime and Oswald Buddenhagen. Description --- Recent versions of GRUB2 introduce submenus which allow for nesting levels to appear (instead of the flat list in the past). This patch consists of two parts: the parsing part in KDM (bootman.c) and creating a menu structure from the parsed list in ksmserver (shutdowndlg.*) The parsing part produces a list like this: Gentoo GNU/Linux Advanced options for Gentoo GNU/Linux Advanced options for Gentoo GNU/LinuxGentoo GNU/Linux, with Linux 3.4.4 Advanced options for Gentoo GNU/LinuxGentoo GNU/Linux, with Linux 3.4.4 (recovery mode) Windows 7 (loader) (on /dev/sda2) ? which is then converted into the menu structure. These full identifiers can be properly used with `grub2-reboot`. More info about submenus: http://ubuntuforums.org/showthread.php?p=10720316 Also check the related bug. The parsing part of the patch can be applied in the KDE/4.9 and master branches as well (tested and working in KDE 4.8.95 and 4.9.x). ksmserver has migrated to QML since then however, and the menu structure has to wait. Currently it looks like this: http://i50.tinypic.com/96bw35.png Related ML-discussion: http://lists.kde.org/?l=kde-core-develm=134160279511422w=2 Update: There is a proper fix now for KDE/4.9 and master: https://git.reviewboard.kde.org/r/105568/ This addresses bug 297209. http://bugs.kde.org/show_bug.cgi?id=297209 Diffs (updated) - kdm/backend/bootman.c 8b834d2 kdm/backend/ctrl.c 5d219fe kdm/backend/dm.h 13e7b45 kdm/backend/util.c 6cd93ef ksmserver/shutdowndlg.cpp a09a1a7 Diff: http://git.reviewboard.kde.org/r/105563/diff/ Testing --- Works with the menu file produced in my system with `grub2-mkconfig`. Also works with a custom menu file I made (as shown in the second screenshot). Screenshots --- Distribution's stock menu file http://git.reviewboard.kde.org/r/105563/s/633/ A custom menu file for testing http://git.reviewboard.kde.org/r/105563/s/634/ Thanks, Konstantinos Smanis
Re: Review Request: Fix Warning messages when closing About popup
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105627/#review16993 --- This review has been submitted with commit 9aaa24814030041f51405182f03c9760e04bc76f by Albert Astals Cid to branch KDE/4.9. - Commit Hook On July 19, 2012, 10:23 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105627/ --- (Updated July 19, 2012, 10:23 p.m.) Review request for kdelibs, Frederik Gladhorn and David Faure. Description --- There is a too agressive check in KWidgetItemDelegateEventListener that complains about User of KWidgetItemDelegate should not delete widgets created by createItemWidgets! when closing an about dialog. I tried making it less agressive but since i could not, i'm just deleting things in a different order in the destruction of KAboutApplicationDialog so that the warning is not triggered and our users get angry This addresses bug 301628. http://bugs.kde.org/show_bug.cgi?id=301628 Diffs - kdeui/dialogs/kaboutapplicationdialog.cpp 2c98f74 Diff: http://git.reviewboard.kde.org/r/105627/diff/ Testing --- Dialog still works, valgrind doesn't complain, the warning is gone Thanks, Albert Astals Cid
Re: Review Request: Allow symlink creation for kio protocols that support it
On Aug. 3, 2012, 8:48 a.m., David Faure wrote: I'm not sure this makes sense. You drag-n-drop a symlink called link to a file called target from fish://myhost to your local $HOME, and you end up with a broken symlink, given that target is nowhere to be found? The logic of the test isn't about does the protocol support creating symlinks (kio_file certainly does), it's about whether it makes sense to copy a symlink as a symlink when copying it out of the original location (protocol+host+port+login). The now-lost bug 5601 was about going into an FTP folder that is full of symlinks (e.g. pointing to release tarballs), and (as a user) copying one of these to your HOME, in order to download the tarball. Ending up with just a symlink is kind of pointless. The exact same case could be made for FISH or NFS, the source protocol is rather irrelevant here. The real problem is what does the user really intend to do here (if you were copying the full hierarchy including the target files then you would probably want the symlinks to stay as symlinks...) Maybe the solution lies in offering more choices to the user, yet again... i.e. when dragging a symlink, offer copy target in the popupmenu, while copyNextFile() (which is also called when dragging entire directories) should copy symlinks as is... Lamarque Vieira Souza wrote: One of the uses for this is archiving a directory with symlinks, specially symlink to a directory. The user may not be interested in archiving the directory itself and currently kio creates an empty file everytime it copies a symlink to a directory (it treats symlinks to directory like symlinks to a file), so nothing is actually copied. David Faure wrote: Empty file? That sounds like a bug in the symlink() implementation of the destination kioslave, no? This code is supposed to create a symlink at the destination. If anything else happens, then that should be fixed, rather than skipping the creation of the symlink. Lamarque Vieira Souza wrote: It's not a bug in symlink() because it is never called by kdelibs when source and destination protocols are different. In that case if you try to copy a symlink to a directory kdelibs tries to copy the target as a file, which obviously does not work when the target is a directory. For example, try to copy ftp://ftp.kde.org/pub/kde/snapshots (a symlink to directory) to your home directory using Dolphin. It will failed with a message ftp://ftp.kde.org/pub/kde/snapshots is a folder, but a file was expected.. That happens because kdelibs is calling KIO::file_copy() instead of KIO::symlink() or CopyJobPrivate::createNextDir(). David Faure wrote: I see. This is not a bug in kdelibs, but in kio_ftp, because it cannot distinguish a symlink-to-a-file from a symlink-to-a-directory (this would require issuing multiple FTP commands, changing directory to the target and listing it). I'm pretty sure that if you try this with kio_sftp there is no such issue? I not aware of any sftp server that I can test kio_sftp. - Lamarque Vieira --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105831/#review16813 --- On Aug. 2, 2012, 9:31 p.m., Lamarque Vieira Souza wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105831/ --- (Updated Aug. 2, 2012, 9:31 p.m.) Review request for kdelibs. Description --- Some kio protocols support creating symlinks but a change in kio/kio/copyjob.cpp hardcoded symlink creation to only when source and destination protocols are the same. That change was added to fix a problem with ftp protocol creating symlinks instead of copying files (there is a comment in the source code about that). I think instead of forcing source and destination use the same protocol we should test if the destination protocol supports creating symlinks (ftp protocol does not). That would allow kio's like fish and nfs create symlinks. I am also working on some other changes that could use this feature. Diffs - kio/kio/copyjob.cpp 8dde763 Diff: http://git.reviewboard.kde.org/r/105831/diff/ Testing --- Thanks, Lamarque Vieira Souza
Re: Review Request: Allow symlink creation for kio protocols that support it
On Aug. 3, 2012, 8:49 a.m., David Faure wrote: Actually we need to test both source and destination to check if their protocols support symlink creation. Haha, if we're copying a symlink, then obviously the source protocol supports symlinks, otherwise it wouldn't be there in the first place :-) Lamarque Vieira Souza wrote: I meant supports *creating* symlinks, not only *showing* symlinks. ftp kio protocol does not support creating symlinks according to its ftp.protocol file. David Faure wrote: So? If you're copying a symlink *from* FTP to the local harddrive, what should it matter, that kio_ftp cannot *create* symlinks? The symlink is there, it exists, so checking whether kio_ftp can create symlinks is totally irrelevant. Only the capability of the destination protocol matters, not the one of the source protocol. Lamarque Vieira Souza wrote: I am using that heuristics to avoid the symlink with ftp problem to come back (bug #5601). If I just test the destination protocol it will always create a symlink if the destination protocol is file. We could call KIO::symlink() if both source and destination are local, do you know a way to detect that besides checking if QUrl::host() is empty? David Faure wrote: You realize how wrong that heuristic is, right? It's testing for something completely unrelated to the operation at hand, just to exclude FTP, in order to work around a problem, which isn't even specific to FTP (the issue that we sometimes want to copy symlinks as is, and sometimes to copy their target). You can detect pseudo-local protocols using KProtocolInfo::protocolClass(url.protocol()) == :local, but this sounds like a hack too. Don't you agree that the real fix would be to copy source URLs (i.e. objects actually dragged by the user) by following symlinks, and to copy symlinks as symlinks otherwise (when we encounter one inside a directory that we're copying)? This doesn't help with the issue that FTP can't distinguish symlinks to files and to directories, but that's orthogonal, let's use fish or sftp as examples instead, if they do distinguish these correctly. I am aware that my heuristic is not a perfect solution. kio_fish shows the same problem kio_ftp does. I like your proposal. If we remove the only run symlink() if both source and destination use the same protocol from kdelibs it works almost like that. Of course, if the destination does not support symlink we must copy the target instead and that can be a problem if the target is a directory. Currently, kdelibs creates all directories first before copying the files inside the directories, but by the time this part of source code run the directory creation loop has already finished. If you are right that the problem of not distinguishing link target type is in the protocol then we would have to fix that for ftp and fish at least. I am not sure that this last problem is in the protocols. I will take a look at this problem when I have more time. - Lamarque Vieira --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105831/#review16814 --- On Aug. 2, 2012, 9:31 p.m., Lamarque Vieira Souza wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105831/ --- (Updated Aug. 2, 2012, 9:31 p.m.) Review request for kdelibs. Description --- Some kio protocols support creating symlinks but a change in kio/kio/copyjob.cpp hardcoded symlink creation to only when source and destination protocols are the same. That change was added to fix a problem with ftp protocol creating symlinks instead of copying files (there is a comment in the source code about that). I think instead of forcing source and destination use the same protocol we should test if the destination protocol supports creating symlinks (ftp protocol does not). That would allow kio's like fish and nfs create symlinks. I am also working on some other changes that could use this feature. Diffs - kio/kio/copyjob.cpp 8dde763 Diff: http://git.reviewboard.kde.org/r/105831/diff/ Testing --- Thanks, Lamarque Vieira Souza
