Ark completely useless in common user scenarios

Fri Aug 29 21:24:08 BST 2014

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 <matteo at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde/attachments/20140829/efc8ac98/attachment.htm>
-------------- next part --------------
___________________________________________________
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.