Version: v2.1.9 (using KDE 3.2.2, Gentoo) Compiler: gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7) OS: Linux (i686) release 2.6.5-gentoo well as the title says, basic support for .ace files would be very nice, if you don't know what it is, take a look at winace.com and unace for linux, much of my old windows files are compressed using winace so it would be nice to have them ready via a nice gui like ark's. Thanks in advance -Janis Blechert
I agree. It should check whether unace is installed or not, and use it in the first case. Regards.
I would need some sample files in order to implement this.
Has meanwhile someone provided the files for you? Do you really intend to implement support for .ace files?
Yes, I received some sample files, though receiving more would be nice (the more I can test, the better). ACE support is currently implemented on my machine, but very buggy. I hope to squash all bugs in time for KDE 3.5.
So KDE 3.5 is out now, what´s the status of the ace support?
Hi! I am with KDE 4.2.3 and Ark 2.12, and it doesn't open my ACE files. Anybody know if the ACE support is under development or not?
There's an unace plugin in the source tree, but it's not maintained. Proper support is a planned feature for KDE 4.4 (see http://techbase.kde.org/Schedules/KDE4/4.4_Feature_Plan).
Created attachment 33459 [details] Ark's dialog box when it's going to open an ACE file Ark's dialog box when it's going to open an ACE file
OK. Thank you, Raphael. :-)
I think remember that this idea was marked to KDE 4.3 instead of to KDE 4.4. Do you need help, Harald? Can someone help to Harald? I'm sorry, I don't know any programming language. :-(
Yes, it was initially on the 4.3 feature plan, but work on other parts (such as cliinterface and general bug fixing) took most of our (short) development time, so work on the ace plugin could not be started before the feature freeze.
O.K. Thank you very much for clarifying the doubts again!
True, ACE was planned for 4.3 but didn't make it to the freeze. But the cliinterface class made it though, and with this class available implementing support for ACE becomes almost trivial (for comparison I spent only about three hours implementing the new zipfile plugin, based on cliinterface). Too bad it will still not hit the end-users until 4.4 though :(
if it is so trivial, may be KDE release management will allow it to be backported for 4.3.1?
I doubt it, even though the plugin itself introduces no new strings, the desktop file defining the plugin does so it would probably not be allowed. But if it's ok with the translators/release team, I have no problems with backporting it (once 4.3 is out).
Guess what, the unace plugin provided all that was needed, and the switch to use cliinterface was a lot more trivial than I had anticipated (I even got to use most of the previous parsing code). So ace support will be in for 4.3
SVN commit 965498 by metellius: BUG: 80778 Modify unace plugin to use cliinterface instead without introducing any new strings. Still a little flaky, but better than it was before. M +48 -87 unaceplugin.cpp M +5 -6 unaceplugin.h WebSVN link: http://websvn.kde.org/?view=rev&revision=965498
Ready for KDE 4.3? That's great!
Moved from KDE 4.4 Feature Plan to 4.3 Feature Plan, and marked as "IN PROGRESS".
Here I am with Ark 2.13 on KDE 4.3.1. I have unace plugin installed and I can confirm that Ark doesn't support ACE files yet. But the most serious is that the related entry has been deleted "mysteriously" from KDE 4.3 feature plan list and also from KDE 4.4 feature plan list. Is this a joke?
...reopen this bug, please.
I believe there were several reasons why we dropped Ark, but I can only remember one of them right now. First there was a bug with the file contents listing being trimmed (long names replaced with "..."), therefore making it unusable as an Ark backend. We found no way to turn off this "feature", so we were forced to give up unace/unace-free (can't remember which one it was who had the problem). Then there is the situation with unace commercial and unace-free, with the commercial one sold to some company, and the free one lacking in features and without any active development. In the end we decided to just cut support for the format entirely in order to avoid weird workarounds (not even sure if there are any). I'm pretty sure there was more reasons too, Raphael if you are reading this, do you remember more?
Stupid typo, I of course meant "why we dropped ACE" :)
Hi there. Most of the discussion about implementing support ACE files is in the comments for bug 192925. Let me past the reasons I gave for commit 970866, which dropped support for the ACE file format: * The format is proprietary and isn't likely to be opened soon. * The only program to decompress unace files is outdated, is usually offered in binary-only form and is even more outdated for non-Linux platforms (think BSD here). * This program is _really_ horrible and does awful things like trimming the file names in its listings, making it impossible to use with cliinterface. * This program doesn't allow the user to create ace files. Just disabling it in the source tree would mean having unmaintained code forever (since things aren't likely to change regarding the format). That said, we cannot properly support a file format that is proprietary, closed and whose only interface is so awful, so I'm closing this report as WONTFIX instead of FIXED ;) Thanks!
OK. Now is clear. Thanks. In the future, I will try to "connect" File Roller with Dolphin for ACE files.