Bug 187152

Same problem here.

By the way, you can vote your own bug and give it 20 votes, just like I'll do :)

(In reply to comment #1)
> Same problem here.
> 
> By the way, you can vote your own bug and give it 20 votes, just like I'll do
> :)

I'm sorry, I didn't say anything about my system.

ArchLinux i686, KDE 4.2.2 from KDEMod, Ark 2.12

This bug is still present in KDE 4.3 Beta 1

This bug is still present in KDE 4.3 Beta 2 :(
Tested from: http://home.kde.org/~binner/kde-four-live/

I think this problem is origined by:

void ArchiveView::slotClicked(const QModelIndex& index)
{
    if (KGlobalSettings::singleClick()) {
        if (m_mouseButtons != Qt::LeftButton) // FIXME: see Qt-issue 176832
            return;

        // If the user is pressing shift or control, more than one item is being selected
        const Qt::KeyboardModifiers modifier = QApplication::keyboardModifiers();
        if ((modifier & Qt::ShiftModifier) || (modifier & Qt::ControlModifier))
            return;

        emit itemTriggered(index);
    }
}

I couldn't try it, but I think this slot is called when you try to drag, so it causes that only one file is selected, unselecting everything else.

Could anyone check that?

Nope, that code is related to a different issue. The unselection is done at ArchiveView::startDrag.

It currently works that way due to the issue related to dragging and dropping multiple files from different folders with no common root node or no common direct ancestor. In this case, it's difficult to determine which files to extract and you might end up extracting all folders above the items you've selected, which isn't what you usually want when you're dragging your items to a folder or your desktop.

According to Harald, it was implemented this way in order to have any support for drag'n'drop for KDE 4.2 at all, and later neither of us have had the time to properly fix it.

As always, patches are welcome ;)

*** Bug 188205 has been marked as a duplicate of this bug. ***

*** Bug 201221 has been marked as a duplicate of this bug. ***

*** Bug 201775 has been marked as a duplicate of this bug. ***

*** Bug 209752 has been marked as a duplicate of this bug. ***

Same problem in KDE 4.3.2 under Mandriva One 2010.

*** Bug 217626 has been marked as a duplicate of this bug. ***

*** Bug 218042 has been marked as a duplicate of this bug. ***

This bug persists on KDE 4.4.1

This bug persists on KDE 4.4.3

*** Bug 238780 has been marked as a duplicate of this bug. ***

The bug exist in KDE 4.5.0

still present in kde-4.5.2

Changing the default assignee in the currently open Ark bug reports to me.

This persists in 4.6.2, in fact this bug just had its two year anniversary.

Still present in 4.6.3

*** Bug 281711 has been marked as a duplicate of this bug. ***

I think even the developers themselves now stopped using Ark … you know why.

I think we can all agree that your trollish behavior and lack of constructive suggestions or patches whatsoever clearly indicate you should be spending your time elsewhere. Please refrain from wasting everyone's time next time you feel like acting like a spoiled child.

*** Bug 297886 has been marked as a duplicate of this bug. ***

Raphael Kubo da Costa: Just checking. The logic behind not allowing multiple individual files to be extracted through drag and drop is that if files are extracted from multiple folders in the archive it would be difficult to determine how to extract the files so that they come out in multiple directories. The issue comes from drag and drop being designed around having a single destination directory instead of multiple ones. If that is correct would it be possible to detect that there are multiple directories from the paths and simulate multiple Drag and Drop events to have multiple destinations?

I think its pretty simple. We have several selections in archive (it is possible to have selected folder and one file in it in addition).
We should unpack all selected in one destination. Just unpack sequentially. One selected after another. Unpack folders and save structure from the selected folder (not the path to that folder in archive).
Example:
Archive:
/folderA/fileA1
/folderA/fileA2
/file1
/folderB/folderC/fileBC1
/folderB/folderC/fileBC2
/folderB/fileB1

Selected to drag-n-drop:
folderA
fileA2
folderC
fileB1

Should be unpacked in ONE destination folder as:
folderA/fileA1
folderA/fileA2
fileA2
folderC/fileBC1
folderC/fileBC2
fileB1

It's simple, isn't it?

Of course it is. Really simple. 

How would you handle the scenario of

Archive:
/folderA/fileA1
/folderA/fileA2
/fileB1
/folderB/folderC/fileBC1
/folderB/folderC/fileBC2
/folderB/fileB1
/folderD/FolderA/FileA3
/FolderD/FolderA/FileA4
FolderD/FolderA/FileA5

Selected to drag-n-drop:
folderA
fileB1
folderC
fileB1 
FolderA

?

after or before (this depend on how the Ark is unpacking: directly to destination or in temporary folder, then coping to destination) second fileB is unpacked the standard KDE dialog should be shown: the fileB already exist - change the name, skip or replace the file. This behavior also applied in case of folderA already exists in destination folder.

That feels pretty ugly for most people esp as the number of files needed increases. Just occurred to me to see if  the archive kio tries to handle this scenario.

I think this scenario is the user problem. User should understand that filenames are the same. If he need to unpack these files - just unpack as many times as needed in any destination, but not for one time. My solution apply user to change the name, for example, if he forgot about same filenames in the archive.
Don't understand what you mean sad "the number of files needed increases". What is "needed files"?

I meant as the user selects more and more files that they expect in a hierarchy. I would expect that as a user I would think without any other information that drag and drop would work the same way as selecting the files and clicking the extract button. having them be so radically different would be jarring everytime. 

What would be the logic behind having them do that?

Because this is standard behavior in other archive programs. If I need only one file from many-level structure in destination, I don't need the whole structure with folder, folder inside first folder, folder inside second folder is inside first folder and so on. I just need the one file.
This scenario (when many file with the same name will be unpacked in one directory) is rare, I think.
When you extract files from Extract button you can change the behavior by clicking checkbox "Preserve paths when extracting". Because this could be changed I couldn't expect the one of these 2 behaviors, cause I don't remember which state I use at the last time.
Just only we - 2 people said the opinion. 25 users are CC'ed to this bug. I think we need their voice about this problem.
If you want, it might be more complicated. For example, after drag-n-drop Ark may show additional menu to user (like dolphin's drag-n-drop produce) with 2 values:
- Make the whole paths structure
- Don't make additional paths
(the text should be another)

(In reply to comment #26)
> Raphael Kubo da Costa: Just checking. The logic behind not allowing multiple
> individual files to be extracted through drag and drop is that if files are
> extracted from multiple folders in the archive it would be difficult to
> determine how to extract the files so that they come out in multiple
> directories. The issue comes from drag and drop being designed around having
> a single destination directory instead of multiple ones. If that is correct
> would it be possible to detect that there are multiple directories from the
> paths and simulate multiple Drag and Drop events to have multiple
> destinations?

I might have started to forget things, but IIRC your explanation is correct, and your solution might work. In the end, this and bug 208384 have pretty much the same cause (and possibly the same solution).

Until i found this bug report, I was wondering why I couldn't drag and drop multiple files into a folder. Please make this a priority, I can't believe this has to be requested in 2012.

*** Bug 309534 has been marked as a duplicate of this bug. ***

This is the only *bug* that I see in stable KDE versions 4.8 and 4.9 please fix and make KDE the ultimate!

Created attachment 77556 [details]
dnd multiply extract

Created attachment 77557 [details]
KXMLGUIFactory

It`s not a bug, it`s seems deliberate restriction. I don`t know why developer doing that, but that patch(^^^ se above message) remove restriction and make it usefull. No have problem allmost, work propertly. Second patch remove message about KXMLGUIFactory ololo, bla bla bla. and avoid(?) leaks, crashs and other terrible problems described in the debug message :)

(In reply to comment #40)
> It`s not a bug, it`s seems deliberate restriction. I don`t know why
> developer doing that, but that patch(^^^ se above message) remove
> restriction and make it usefull. No have problem allmost, work propertly.
> Second patch remove message about KXMLGUIFactory ololo, bla bla bla. and
> avoid(?) leaks, crashs and other terrible problems described in the debug
> message :)

Please create a review on https://git.reviewboard.kde.org where the responsible developer (and others) can comment on details of the patches until they're ready to get their "Ship it".

*** Bug 319698 has been marked as a duplicate of this bug. ***

This is literally one of the very few weak links of the standard distribution of KDE SC. I can't believe Ark doesn't do this and it's unbelievably infuriating for me who often works with large archives.

*** Bug 320405 has been marked as a duplicate of this bug. ***

Who is the main developer/maintainer of ark?

(In reply to comment #45)
> Who is the main developer/maintainer of ark?

See about in ark. Also, I`m pushed patches on review board. Still awaiting... Already tired always patching myself package when upgrading.

(In reply to comment #46)
> See about in ark. Also, I`m pushed patches on review board. Still
> awaiting... Already tired always patching myself package when upgrading.

You should ask on the kde-devel mailinglist for somebody to review your patches and to change the maintainer.

Even GNOME's archive manager can do this...

*** Bug 328058 has been marked as a duplicate of this bug. ***

Vova, if you patch works, it would be great to have it integrated in ark. Have you submitted it to https://git.reviewboard.kde.org ?

When using drag-n-drop the last selected settings from the extract dialog could be used. Thus you'll have consistent behaviour (the drag-n-drop would work the same as the extract button) and better usability - the user will be able to do drag-n-drop for multiple files). Also, I guess this could also be achieved by making the drag-n-drop as clicking the "Extract" button while passing a path as parameter.

(In reply to comment #51)
> When using drag-n-drop the last selected settings from the extract dialog
> could be used. Thus you'll have consistent behaviour (the drag-n-drop would
> work the same as the extract button) and better usability - the user will be
> able to do drag-n-drop for multiple files). Also, I guess this could also be
> achieved by making the drag-n-drop as clicking the "Extract" button while
> passing a path as parameter.

While not the best or most elegant solution in the world, this will be usable. Then later on this can be changed to something like having an option whether to show some UI when dropping multiple files, similar to the "extract" dialog, but adapted for the case of drag-n-drop.

Actually, as a user, I will accept and get used to anything that does the trick. I guess most users will also do.

As for the specification how this should be done to me, it is very simple:
Ark should use the exact same logic as in dolphin, the problem is solved there and works as expected (what I refer to is dolphins ability to show the contents of folders 'inline', allowing multiple selections). 
Is this what the suggested patches do?
Could Ark reuse the code from Dolphin?

Still in KDE 4.13 - EXTREMLY+++ annoying!

very annoying :-(

Vova, any news about the patch being accepted?

Vova, can we have a link to your reviewboard request?

He posted comment #38 as https://git.reviewboard.kde.org/r/110672/

(In reply to comment #58)
> He posted comment #38 as https://git.reviewboard.kde.org/r/110672/

Cool. Finally (?)

... wait ... "by removing the code that singles the selection." ... who had this _great_ idea of making the selection single ... ? o_o

Git commit 52ac4aea6f391cfe43dec0994891095d39364bd2 by Albert Astals Cid, on behalf of Alim Gokkaya.
Committed on 06/08/2014 at 22:22.
Pushed by aacid into branch 'KDE/4.14'.

Allow multiple selection in archiveview

REVIEW: 110672
FIXED-IN: 4.14.0

M  +0    -2    part/archiveview.cpp
M  +0    -7    part/part.cpp

http://commits.kde.org/ark/52ac4aea6f391cfe43dec0994891095d39364bd2

Git commit 4429a4ebbb58f44e4c96603f6bc519da8c0ce5da by Raphael Kubo da Costa.
Committed on 07/08/2014 at 21:29.
Pushed by rkcosta into branch 'KDE/4.14'.

Revert "Allow multiple selection in archiveview"

The commit being reverted seems to work fine for the ZIP and LHA
backends, but for libarchive and RAR it can extract files with the wrong
name, a varying hierarchy depending on which of the selected entries is
being dragged or sometimes even leave selected entries out.

While it is certainly bad to go back to the previous state, it is worse
to have this working at varying degrees in each backend, the worst case
including partial extraction with wrong names.

This reverts commit 52ac4aea6f391cfe43dec0994891095d39364bd2.

M  +2    -0    part/archiveview.cpp
M  +7    -0    part/part.cpp

http://commits.kde.org/ark/4429a4ebbb58f44e4c96603f6bc519da8c0ce5da

*** Bug 340626 has been marked as a duplicate of this bug. ***

I'm the guy who originally intentionally made it like that (as former Ark maintainer) for technical reasons like Roger Pixley describes here: https://bugs.kde.org/show_bug.cgi?id=187152#c26 . Before those commits, I don't think dnd was even supported. I eventually realized how complex multiple selections are to support with regards to destination directories and just made it force it into a single selection in order to even support dnd at all. The timeline after this is unfortunately a pretty common one in FOSS: you either lose interest or other life events keep you from spending time on the project.
I'm sorry I'm not able to be of any help.

Multiple drag'n'drop selection has actually been implemented and is currently undergoing review:
https://git.reviewboard.kde.org/r/124018/

Hopefully, we can merge it before 15.08 final release :)

Git commit 2072d0d49a8946b62ebb8b3cb961c512ad1f8a25 by Ragnar Thomsen.
Committed on 10/09/2015 at 11:55.
Pushed by rthomsen into branch 'Applications/15.08'.

Fix drag'n'drop extraction of multiple selected archive entries

This commit implements multi-selection drag'n'drop extraction. This is
used when dragging multiple files from Ark to e.g. Dolphin for
extraction. It's based partially on work done by Raphael in
the multiple-dnd-selection git branch.

Dragged files are extracted without path. Dragged folders are extracted
without path, but with all folders/files beneath them
extracted with relative path (i.e. path beneath the selected folder).

A struct called FileRootNodePair is added to Kerfuffle::Archive, which
contains two strings (the filename with path and a root node).
A FileRootNodePair is passed for each entry to be extracted in a
QVariantList to ArchiveModel::extractFiles(), which creates the
ExtractJob. All children of folders are added to the QVariantList. The
QVariantList is in turn passed to CliPlugin::copyFiles and hence
LibArchiveInterface::copyFiles(). The latter is modified to remove the
specific rootnode from each file when extracting.

The CLI plugins, e.g. clizip and clirar, still extract with full path,
due to not supporting individual RootNodes. However, this is a separate
issue and should be fixed separately.
FIXED-IN: 15.08.1
REVIEW: 124018

M  +9    -0    kerfuffle/archive_kerfuffle.cpp
M  +39   -0    kerfuffle/archive_kerfuffle.h
M  +1    -1    kerfuffle/cliinterface.cpp
M  +1    -1    kerfuffle/jobs.cpp
M  +1    -1    part/archivemodel.cpp
M  +0    -2    part/archiveview.cpp
M  +48   -65   part/part.cpp
M  +3    -2    part/part.h
M  +44   -13   plugins/libarchive/libarchivehandler.cpp

http://commits.kde.org/ark/2072d0d49a8946b62ebb8b3cb961c512ad1f8a25

*** Bug 359564 has been marked as a duplicate of this bug. ***