| Summary: | Ark not kio-slave capable | ||
|---|---|---|---|
| Product: | [Applications] ark | Reporter: | Marcel Partap <mpartap> |
| Component: | general | Assignee: | Elvis Angelaccio <elvis.angelaccio> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | alexkde, anderslund, aspotashev, b.brachaczek, bugseforuns, christian.gonzalez, finex, giovanni, grahamperrin, illumilore, kollix, mahen, mail-kdebugs, nate, nt1277, p3dimaria, postix, rakuco, redstar, sjakub, tempel.julian, vdboor |
| Priority: | HI | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=75324 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Marcel Partap
2009-08-18 20:51:41 UTC
btw i tagged this bug because it LOOKS like it is successfull, i.e. the cursor changes to a plus and something happens. But the result is not what was intended. *** Bug 208384 has been marked as a duplicate of this bug. *** *** Bug 167730 has been marked as a duplicate of this bug. *** I'm not sure if bug 208384 is really a duplicate since this talks about remote-KIO but the problem with creating the subdirs also happens with a locally opened zip file in ark *** Bug 229185 has been marked as a duplicate of this bug. *** Martin, you're right; I've reopened bug 208384. Changing the default assignee in the currently open Ark bug reports to me. *** Bug 272282 has been marked as a duplicate of this bug. *** *** Bug 240716 has been marked as a duplicate of this bug. *** *** Bug 291437 has been marked as a duplicate of this bug. *** Same problem here, in 4.8.0, when extracting a file by D&D to the Plasma desktop, if the desktop is in "Folder View" mode (that is to say, if the whole desktop is set to display a single directory). However it works when D&D'ing to a "Folder view" widget. The extraction is successful, as, If I do the operation again, Ark asks me if I want to overwrite the file. For some strange reason, the extracted file appears in my "Documents" folder and my "Documents/Articles" folder, the latter being the path of yet another Folder View on a different activity... One additional remark : when the desktop is entirely in Folder View mode, if the specified location is "Display the desktop folder", the bug occurs. However, if you specify "display the place" -> "desktop" it doesn't occur. (In reply to comment #11) > Same problem here, in 4.8.0, when extracting a file by D&D to the Plasma > desktop, if the desktop is in "Folder View" mode (that is to say, if the whole > desktop is set to display a single directory). > > However it works when D&D'ing to a "Folder view" widget. > > The extraction is successful, as, If I do the operation again, Ark asks me if I > want to overwrite the file. For some strange reason, the extracted file appears > in my "Documents" folder and my "Documents/Articles" folder, the latter being > the path of yet another Folder View on a different activity... This doesn't really look like the problem described in this bug report. Could you open a separate report for us to track it? Raphael : ah ! I thought it might be related (desktop:// path ?). As advised, I created this bug report : https://bugs.kde.org/show_bug.cgi?id=294904 Thanks for your reply ! *** Bug 320820 has been marked as a duplicate of this bug. *** *** Bug 332157 has been marked as a duplicate of this bug. *** Git commit 4f7a4572d74d7e2d7fa98fd1039458b0f13f6585 by Elvis Angelaccio. Committed on 08/12/2015 at 22:00. Pushed by elvisangelaccio into branch 'master'. Prevent drop events to non-local destinations We already prevent users from extracting to a non-local destination, when they use a KFileWidget. The same should be done when they drag-and-drop to a non-local destination in e.g. Dolphin. Differential Revision: D565 M +10 -2 part/part.cpp http://commits.kde.org/ark/4f7a4572d74d7e2d7fa98fd1039458b0f13f6585 *** Bug 397741 has been marked as a duplicate of this bug. *** (In reply to Elvis Angelaccio from comment #17) > We already prevent users from extracting to a non-local destination And why is that? This limitation makes no sense and only cause headache when you have to extract archives to remote directories. (In reply to Hirad from comment #19) > (In reply to Elvis Angelaccio from comment #17) > > We already prevent users from extracting to a non-local destination > > And why is that? This limitation makes no sense and only cause headache when > you have to extract archives to remote directories. Because no one has wrote the code to implement this feature yet. |