I think the comments in this thread well explains why Ark hasn't been fixed. Some of them are pretty interesting for being used on a list for KDE.
/Martin Sent from Blue Mail On 29 Aug 2014 02:42, at 02:42, Matteo Italia <mat...@mitalia.net> wrote: >Hello, > >it's probably about 2 years since I switched to KDE, and it's mostly >been a pleasant journey; but since day zero, I've always had problems >with Ark, which, in my opinion, has several known bugs which really >cripple with the most common usage scenarios. > >Suppose that a new KDE user - coming from WinRar, 7zip, PeaZip, >XArchiver, FileRoller, whatever - wants to open some document inside a >zip; he double clicks on the .zip and ark shows up. Nothing >particularly >strange here (althought the UI could be somewhat less minimal). > >He double clicks on a file inside the archive and a "preview window" >shows up. >Perplexity ensues. > - I don't want to see a .cpp file in a dumbed-down Kate; >- I don't want to see PDFs in a stripped-down Okular where I can't >print; > - I don't want to open a complicated ODT in the same stripped-down >Okular to see the formatting break; > - and the best of all: I don't want to double click on an ODS file to >see an even more dumbed-down ark showing me a bunch of XML files. Find >me any user who would think that this is expected behavior. > - no, actually, there's something even better: if you have a .zip >inside another zip, it will open _a preview of ark_, which allows only >to open previews (so, no way to actually extract anything from nested >zip files) > >Let aside the technical problems; from the UX viewpoint, this stuff is >completely broken. Why should the archiver show by default a lookalike >of the default KDE application with 90% features less (doubly bad - you >recognize the "internal" of Okular, you know that "the real thing" can >print, so you waste time looking for a feature that it's not actually >there) if you are lucky, and unintelligible garbage if it guesses >wrong? >I have my applications and my file associations to open my files, who >asked the archiver to guess (badly) what kpart it should use? > >(fun fact: the issue has been first reported in 2008 - see bug 179066 - >and two patches has been proposed, none actually merged) > >Let's get back to our user. Ok, double click yields garbage, let's see >if we can get the data out this thing. I don't think I would guess >wrong >if I said that, coming from any other archiver, the most obvious thing >to try would be to drag & drop the file on the desktop. > >Sad trombone. >You lost, but thanks for trying; directly from 2012, bug 294904. >The file does not appear on the desktop, so the user will assess that >the functionality is broken (sadly it's not rare on a Linux desktop to >see drag & drop broken). What he does *not* know is that the file >actually got extracted, but in the home directory (probably). >(this actually is a problem with any KIO path - the desktop folder view >- which points to desktop:/ - just happens to be the most common >scenario). > >Unaware that his file is in the home (he'll find out in a few days by >chance), the user still tries to get his data out of Ark: "Well, this >thing sorta looks like a file manager, let's try to copy out the file". >Right click, nothing happens (this rules out also the hoped-for >possibility of an "extract single file" context menu, or of a hidden >"Open" menu item). He might try Ctrl-C in Ark and Ctrl-V in a folder, >without success. > >Our user gets smart, selects the file, looks at the toolbar, and clicks >on the "Extract" button; the hideous folder select dialog (it's still a >mystery to me how file dialogs look natural and work beautifully but >any >folder select dialog I ever saw is a nightmare at some degree) shows >up, >asking for confusing stuff. > >Mind you, this dialog may be fine for the "advanced" case, but it's >just >not acceptable as the mandatory UI path to extract a PDF to print it. > >Wait: maybe our user is smarter; he might have seen the little arrow >near the extract icon; or, more probably, he went hunting through the >menus (at least from what I always read around, menus are normally used >to get a grip of what a program can do, or, as in this case, as "last >resource" after looking for a feature everywhere). Anyway, somehow he >managed to summon the "Quick extract" menu, with its list of locations >coming from I don't know where. At least on my machine, I see the path >of my desktop, so I click on it. > >The single file I selected gets actually extracted on the desktop. > >Along with all the empty directory structure it was stored in inside >the >zip file. Terribly useful indeed, who doesn't like a trip through three >levels of directories to finally reach the PDF he should have opened >with a double click? > >--- > >Now, all this stuff is ridiculous. I remember friggin' WinZip doing the >right thing in Windows 95, maybe even before; when using Gnome, >file-roller never had these problems (but can't be used profitably with >KDE because drag & drop is broken as usual), it's not like it cannot be >fixed because 2014 technology isn't powerful enough. And most >importantly, any solution is better than the current state, because an >archive program that cannot deal with the most common use case for >extraction (after right click on the zip file -> extract all, which >luckily seems to work fine) is complete junk. > >Coming to think of solutions, I dabbled a bit with KIO handlers for >zip/tar files, and I must say that, although not without issues when >going in dark corners (see my new bug 338643), it's a huge step forward >in terms of user friendliness. I replaced the association of zip with >`xdg-open zip://%f`, and for tar (even compressed ones) with `xdg-open >tar://%f`, so when I double-click on a zip I get a new Dolphin window >browsing the compressed file. >This avoids all the UX problems seen above: double click works as >expected, copy-paste works fine as well; more in general, you get a >fully-fledged file manager instead of the abortion found inside ark. > >Now, writing is not supported; IMHO, this is mostly a non-problem - I >know nobody who expects to perform modifications on files in archives - >probably, most people don't even know that zips can be updated >in-place. >The most common workflow I see is to extract files (single files via >the >archiver or entire archives via the context menu) and compress entire >directories (via the context menu), so, as long as it's clear that the >path is readonly (and there's no risk in losing data) this limitation >should be reasonable. > >(in reality, writes by programs inside KIO read-only paths should be >handled more gracefully - besides the above mentioned bug 338643, the >files extracted through KIO in its magic directories from read-only >paths should just be marked read-only, to avoid any mistake, or at >least >a choice of saving elsewhere should be proposed when detecting the >change, instead of the current "Read only location - ha ha, you lose, >say goodbye to all the edits you did" dialog) > >Well, that's mostly it; I hope to hear some opinion on the issue from >other KDE users. > >Best regards, >Matteo Italia >___________________________________________________ >This message is from the kde mailing list. >Account management: https://mail.kde.org/mailman/listinfo/kde. >Archives: http://lists.kde.org/. >More info: http://www.kde.org/faq.html.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
