Ark completely useless in common user scenarios

[Matteo Italia]

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.