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