Ark completely useless in common user scenarios

Fri Aug 29 12:57:42 BST 2014

On Friday 29 Aug 2014 02:42:02 Matteo Italia 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.

i've never had any problems with Ark myself but then again i don;t use it 
much.

Have you logged any errors in the bug tracking system ?  You'll also need to 
provide some version numbers of Ark/KDE etc you are using for someone to make 
any useful replies.

> 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.