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.