Archive for the ‘Ark’ Category

Tip of the day: Quickly extract archive from command-line using Ark

August 28, 2009

Here’s a little tip you might enjoy. I’ve been using this for some time now whenever I’m too lazy to remember how to extract something.

To extract any archive, and create a subdirectory if there is none in the archive, use this:

ark -b -a [archive(s)] …

-b is short for –batch, and just signifies that this will be handled without using the GUI. Note, that the KDE notification area will still be used for progress display.
-a is short for –autosubfolder, which creates a directory as mentioned above.

Have a look at ark –help for more things that can be done with the batch interface.

Drag’n’drop menus/Ark “extract here” popup menu

April 2, 2009

KDE Brainstorm is great, when I was a little bored of fixing bugs and started feeling tired of the same code all the time, seeing peoples ideas once again brought me back to the coding mood. What they suggested this time was a menu where you can drag an archive file, and have “Extract here” pop up in the menu at the destination where the file is dropped. Looking at dolphin/libkonq code I saw that there was a TODO for actually bringing this kind of functionality back (remember dropping an image file on the desktop and getting “set as wallpaper”?) So I dived in and started hacking on a new plugin architecture for adding this kind of popups.

At this point the code has not been polished and is not ready for commiting yet, but it will be in a few days I think. Screenshot:


For anyone that want to extend their application with an item like this, now is the time to act to get it ready in time for 4.3. The “set as wallpaper” plugin will also be trivial to implement and is up for grabbing for anyone looking for a junior/junior high job.

These kind of conveniences are, in my eyes, the small but important things that made KDE what it is.

Ark: new cli-interface opening for junior jobs?

March 20, 2009

Greetings fellow KDE coders. Here’s a quick update on what I’ve been working on lately. Apart from the bugfixing (which there have actually beenquite a bit of to get ark stable lately), I’ve been working on a new interface that makes it very easy to implement a new plugin for your favorite archive format. Uptil now, implementing a new format meant handling the whole process execution, and parsing the input etc etc. So I’ve been trying to create a class that generalizes this whole interaction with process-based archive formats: the cli-interface.

With this new class, all that is needed to add support for a new file format is a class with two functions: one that is called for every line of the file listing, parsing the output and emitting file entries that are passed onto Ark, and another one that supplies a QHash containing all kinds of properties describing how to interact with this process (for example, a regex looking for a “file already exists” message, how to respond when this happens, how to tell the process to delete a certain file, etc etc.) An api listing of the properties defined so far can be found here.

The whole point of this class is to make implementing a new class less of a hassle than it was before. Once support for adding and deleting files has also been added, I hope people can either take up any of the file format requests on as junior jobs and implement the format, or even just mail me a list of the various properties for your favorite archive format. Eventually I hope to be able to reach the same number of file formats that Ark for KDE3 supported.

EDIT: just in case someone was curious, here’s an example of the parameter list for the rar-format (so far).

virtual ParameterList parameterList() const
static ParameterList p;
if (p.isEmpty()) {

p[CaptureProgress] = true;
p[ListProgram] = p[ExtractProgram] = p[DeleteProgram] = p[AddProgram] = “rar”;

p[ListArgs] = QStringList() << “v” << “-c-” << “$Archive”;
p[ExtractArgs] = QStringList() << “$PreservePathSwitch” << “$RootNodeSwitch” << “$Archive” << “$Files”;
p[PreservePathSwitch] = QStringList() << “x” << “e”;
p[RootNodeSwitch] = QStringList() << “-ap$Path”;

p[FileExistsExpression] = “^(.+) already exists. Overwrite it”;
p[FileExistsInput] = QStringList()
<< “Y” //overwrite
<< “N” //skip
<< “A” //overwrite all
<< “E” //autoskip
<< “Q” //cancel

return p;

A rule for everybody who’s thinking about styling a button

January 21, 2009

I wish there was a rule from the start when designing KDE4. Whenever you really really need to not use one of the already very nice default Oxygen style buttons, and can find no way around actually creating your very own custom look button, please, PLEASE do it all the way and make sure it has unique, clear looks for the normal, hover and pressed down state.

Looking at the 4.2 desktop now I see so many widget elements breaking this rule. The most obvious (and possibly also the most important) is the start button – which has only one hover picture. When you press it you get no feedback at all, and the mental image I get every time I click that button is hitting my fist against a brick wall (why? it’s hard to explain, it just feels so hard and unmovable without the proper visual feedback).

Actually, when I think about it, this is actually the same for _all_ the buttons I have on my bottom panel. Including the systray expander button, which actually doesn’t even have a hover state. The task list is an exception, that one is actually doing it right. (Not that that one gives me a lot of feedback either with the all too subtle color change it has, but that’s really a problem with the current style, and not kde by itself).

A quick end note, to be honest, this was actually the kind of things I set out to fix when I slowly started KDE development some time back with ui improvements to Ark. I eventually got stuck maintaining ark instead, and these small annoyances that I have been thinking about for way too long, had to wait in the back of the queue while Ark was getting fixed from the bruised and bad condition that I found it in.

Ark: First password protected RAR file unextracted

August 2, 2008

So I finally managed to find a clean way to bring passwords into Ark without disturbing the interface too much. So far, passwords are a property set on a current archive, and used for all files that are encrypted/protected. Differing passwords for different files are not supported (has anyone even seen this used?) A new contributor, Yew Ming, has started hacking on the Ark codebase. The first feature he is working on is 7zip support for Ark. Hopefully we can gradually get Ark up and living again. Also, I was recently made the new maintainer of Ark, despite my efforts to just limit this whole thing to a few interface improvements. I guess anything is better than the dead state it was in until recently. Henrique Pinto, if you’re reading this, I have quite a bit of questions I’d like to ask you about the Ark architecture. Several people seems to be unable to reach you from the KDE email. Any other place I can reach you?

Long-lasting drag/drops in ark, and xdnd timeouts

July 17, 2008

I’ve been working on trying to get Ark’s drag and drop to work again, and one of the goals I set is to get it more stable than before. One of the most important things to me then was to trash the old method, which was to first extract the file when the drag was started, and then let the user place it. This failed bad whenever you would try to drag a large file from ark and annoyed many a user.

So I thought, this time I’ll find a way to extract the info only when the drag is actually successfully completed. So following a tip from David Faure on irc, I happily started implementing QMimeData and making my own extract-files custom mimedata class. It would work by extracting the file when retrieveData is called, while at the same time showing a progress dialog. Now, laying some weird interactions with dolphin aside, what surprised me was the buggy behavior I saw once the extractions actually took more than 5 seconds. I eventually found this limit to be exactly five seconds, and grepping around in qt’s kernel classes, in the x11 dnd implementation I found this:

// timer used to discard old XdndDrop transactions
static int transaction_expiry_timer = -1;
enum { XdndDropTransactionTimeout = 5000 }; // 5 seconds

I didn’t dig much more than this, because some google searches also seemed to confirm that getting drag and drop implementations seem to be mostly timeouted. So what do I do know? Is this a bug in the dnd implementation, or am I simply trying to use drag/drop the wrong way? Is there another way I can do this? To simplify, here are the constraints I am trying so hard to get around:

  • The solution must be using drag and drop
  • The destination application will only receive a “text/uri-list” mimedata object with the location of temporarily extracted files (ie no custom mimetypes the receiving app needs to have implemented)
  • The extraction should only take place once the drag has been completed successfully
  • The extraction should be allowed to take long times (people extract really large stuff these days), without bugging up either the source or destination application.

So is there a way out of this?

Oh, and if you’d like to try my test application for these long delays, it can be found here.

EDIT: The blog linked me automatically to an entry about XDS:
Might this be what I want?

Ark: service menu, password protection files and more

July 12, 2008

Time for another update on my Ark changes!
Let’s just do it simple, I’ll put some screenshots here and I’ll explain along:

The batch extract/extraction progress

This is probably the feature I’ve been working most on. After modifying the libarchive plugin and doing some calculating of how much is to be extracted, the extraction shows very nicely and accurately how far it has come in the total extraction. It will also extract many files in a row when given from the command line. Now, some users might wonder (some might even complain) on why I’m even making a command line tool with gui feedback at all. Some of the other users again, will understand immediately just why this comes in handy, which brings us to the next point:

The dolphin/konqueror service menu

With the batch extraction in place and ark taking lots of nice parameters, implementing the service menu for dolphin/konqueror is a breeze. I haven’t completed it fully so far, but above is a quick preview of what’s working so far. Next up here will be a small submenu, showing additional entries such as “Extract to…”, “Extract all to subfolders”, etc. (I haven’t really decided which use cases deserve a menu entry here, feel free to discuss this in the comments section).

The (once more) redesigned extract dialog

So after playing with several solutions of how to actually informing the user of the auto-subfolder mechanism, I eventually decided that the best way to make it natural while not doing too much uncontrollable magic in the background is to first check if the archive is a single folder archive, next use this information to enable/disable the checkbox and informing the user why this choice has been made.

Password protected archives

Finally, there is the password protected rar files that was mentioned in the comments by a user in a previous blog entry. At first I was surprised to see that there was simply no support for passwords at all in the new archive framework, but after coding a little bit I was once more again impressed about how solid the ark codebase is, and how easy it was to add this extra property to the display. So far rar and zip files are checked for password protection, and the display reflects this. Next up is querying the user for the actual password, and finally getting that password all the way to the extraction code.

Another thing that surprised me was that libzip, which is what ark uses for zip files, doesn’t support reading/writing password protected archives yet. A way around this now would be to either 1. switch completely to using the command line zip utility, like the way rar is handled now, 2. switch to the cli zip util only for password protected files, or 3. pull out the relevant extraction functionality from the cli zip util, and include this as another zip plugin for ark. What do you think?

Ark: some help on software design please…?

July 1, 2008

The last few days I’ve been a little stuck on the Ark coding due to design decisions, but eventually figured a blog post to the community would get the right answers right away. (What I’m currently focusing on building is building a batch extract interface for ark, accessible through command line arguments and only shows the user the progress in a simple progress dialog, exiting when finished.)

Ark is divided into several parts:

  • part – the kpart along with the interface
  • app – the (relatively) trivial application that houses the kpart
  • kerfuffle – the extraction library base
  • plugins – the library plugins

The problems showed up when I tried to let the main app also take some arguments to instead of opening the file in a part, opening the part hidden and extracting the files one by one through it. It works fine with a single file, but once I want to do it sequentually I need some kind of a signal to do it sequentually. I went back and forth between several seemingly possible solutions, and eventually questioned how proper it actually is to use the kpart in this fashion (eg. using it almost like a library, and not showing the widget to the user). My motivation was to reuse the archive handling code already in ark’s kpart code, but if this reuse again introduces lots of ugly workarounds to actually make it work I’m not so sure anymore.

So here’s the solutions I currently see possible, I’d like some feedback on which one is the “KDE way”:

1. Ignore the need for a “finished” signal, and instead use an isBusy() function with a QTimer. ¬†Extraction is still done through the KPart
My initial approach, aiming towards shaking as little as much of the existing ark codebase.

2. Start with a new “batch” subfolder, an command application that does not use the KPart, but instead kerfuffle extract library and its plugins.
Would need a lot of reorganising, but could also be a way of further single out the actual extracting code from the kpart into externally available classes. Could end up with some code duplication and/or reimplementation, for example with regards to error handling during extraction. Could also to a light degree split coding efforts between the batch interface and main application.

3. Abstract the extraction into yet another class, and recode the KPart to use this instead (maybe even treating the single extraction as a special case of a batch extract).
The batch operation will be then handled in the same application as the one housing the kpart. Would also probably be the source of new bugs, but fixing them would stabilize extraction/error handling in both the kpart and the batch extract interface. What kind of stops me with this one is I’m unsure if what I’m doing here is overabstracting the already abstract kerfuffle interface, or if it can be seen as adding another layer for simplifying the lowlevel kerfuffle library.

4. Is there a better way out of this chaos?
Maybe just give up? Do people really want the batch extract interface?

To summarize it, am I trying to use KParts in a way seen as incorrect? How much abstraction/ripping the code apart is just right? I kind of keep scaring myself with thoughts of future problems with bad decisions leading to tons of bugs and responsibilites i can’t handle..

EDIT: The kerfuffle archive was actually much easier to handle than I thought before writing this post. I’ve reorganized a few files now and found a quite elegant solution (variant of #2), avoiding code duplication by moving some parts of the KPart into the kerfuffle library. Thanks for the comments received.

Ark’s interface changes: another progress update

June 28, 2008

OK, time for another update. The code that I mentioned in my last post has been properly cleaned up now. I would like to thanks for all the comments I received, it was more than I expected. There was also a lot of feature requests, and I have been working on implementing/testing the most requested ones:

Using the KHistoryCombo instead of a custom listwidget for recent history entries
Ok, I ripped out the listview and am letting the kdirselect dialog do its magic for now. The only problem is though, that for the quick extract all submenu to do it’s thing it needs to read the recently used folders from the dirselectdialog. There is as far as I can see not a properly defined way ¬†to do this, but for now it works fine by just reading the global KConfig entry that contains these directories. A consequence of this though, is that recently used directories are shared between all kde programs and all kinds of directories will appear in the quick extract menu. Is this a downside or upside? I’m not sure, really.

Preserving paths should be better handled
There are many different use cases to when you might to want to preserve paths or not, but I think the most common two ones are 1, you just want to extract it all with paths, and 2, you want to extract two or three files and don’t want them spread all over an almost empty directory structure. Ark does its best to set the dialogs to sensible defaults, but for the special cases a checkbox for preserve paths on/off has been added.

No double subfolders – Ark should be intelligent enough to not create double subfolders when extracting
Now implemented; Ark checks to see if there is just a single folder in the archive, and if so shows the user the detected subfolder name and takes care not to create double subfolders. Ark will also by default extract archives without subfolders into a single subfolder named after the archive.

Ark should be prepared for usage through dolphin/konq service menus
Now being worked on: So far ark accepts an –extract argument that will immediately show the extract all files dialog after opening the file. In most cases however, you don’t want to have to press enter and just want things to go smoothly, and for this reason I have started writing a batch extract interface. This will live next to the usual mainwindow interface, and can be activated by passing the –batch argument. The batch interface will simply extract all archives passed to their respectively subfolders and show the progress while doing it.

Lastly, the only screenshotable change is the slightly redesigned extract dialog. Enjoy!

My git repos for these changes is being pushed regularly to my public github repos here:

Oh, and Aaron, we miss you!

Making Ark’s extraction interface more efficient

June 25, 2008

Hello planet, my first post here. Be nice to me. I will start directly with the thing I’ve been hacking a bit on the last few days. Ark has always been one of those apps that does what it’s supposed to do, it extract files, but it doesn’t really make any attempt to be efficient or smart at it. For example, extracting a file required you to press the extract files button, next click another button to open the folder selector, choose the folder, return to the previous dialog and then press OK once more as seen here:

To reduce the number of clicks required for this operation, I hacked a bit around and discovered it was actually trivial to just set the extraction dialog to inherit from the KDE default folder selection dialog and add my own widgets, and got the result shown below. I also added a list view where the recent folders used can be displayed.

Finally there is the quick-extract functionality. You’ll see the extract button has gotten a dropdown button menu where your recently used folders will appear for quick extraction.

It’s obviously too late to get changes like these into 4.1, but I expect to get these changes commited and ready in good time before 4.2. Comments?