it's done!
After starting KI3U a half year ago I just wanted to learn programming KDE/Qt4. However: Lately, developing it became a passion 8)
First, somehow existing GUIs for rsync didn't fit my taste - a good reason to stick with KI3U, even if I am the only one who will ever use it ;) And then of course the learning factor. The project started pretty simple: "I want to develop something for the KDE desktop environment". S/th I did not since the times back when I used Windows and Delphi/Lazarus (of course my wish then was to develop Windows desktop apps).
So some six month ago I just started developing KI3U - as a replacement for the shell scripts I used up to then. "Simply started" however is meant as written: There definitely was not much planning: I just started programming, as of course learning how to use KDE's and Qt's SDKs was more important than clean and extravagant code.
However, after I somehow managed to send one of the archives files containing several files ( practice sheets, old examination papers, ... ) of an earlier semester into Nirvana I realized that KI3U would need at least a little bit cleanup and restructuring. Beneath, the list of issues in our bug tracker got pretty long, too.
Now ( holidays are nearly over ) KI3U is back 8) Upcoming version 0.1 is basically a complete rewrite, introducing some cool features e.g. a completely plugin driven model. This allows to really write new plugins fast (before, the whole system was designed to be extensible, too, but writing new backends required to extend the applications core sources). The new version uses KDE's Service Trader framework to find its plugins and dynamically load them when starting. Additionally, there now is a clear division between user interface and the plugin/task framework used internally.
Btw: The ladder one allows new interesting things, too. So there will be a "group" plugin which can be used to execute several backup tasks in a row. So one can think of a task as an "atomic" operation. E.g. when I want to synchronize data between my working laptop and my EeePC: I usually keep my files in big main directories (Music, Pictures, devel, Documents, ...). So to synchronize data I would create a pull (or push) job (depending on whether the operation is triggered from the laptop or the Eee). Then I could either do a quick sync (e.g. when I don't have much time and just want to pull the new state of the Documents directory to the Eee to have everything a/v what I need in the university) or I could create a Group task that executes all the smaller sync jobs (so that they finally would make up one big job).
By letting every task access the complete infrastructure such a group plugin is pretty easy to realize. But not only this. KI3U can even be extended to include pretty "strange" plugins (meaning ones that at a first glance don't seem to fit in). So for example one could write a plugin that automatically mounts a remote file system (e.g. via SSH, FTP, etc using fuse) into the local file system. Together with an associated unmount task one can then create a group that would
- mount the file system
- synchronize the data (i.e. pull or push the data that changed or make a clean sync)
- unmount the file system
Other plugins could realize tests and depending on the outcome execute on or the other associated task; e.g. test if computer backupserv is reachable, i.e. we are at home, then call the sync job that uses the backupserv hostname. Otherwise, run the task that contacts the server making a DNS request first (e.g. if we made it accessible via an DynDNS account) and maybe syncs only the most urgent things (e.g. documents but not music and pictures).
Last but not least: The new infrastructure also got rid of the Singleton design pattern used for the global storage in 0.0.x versions. I know that Singletons (and static classes holding global data) are pretty popular and easy to use, because you don't have to pass around pointers and the net between the classes remains pretty small. But in the case of KI3U (and a lot of other apps, too) it caused pretty much struggle. So KI3U crashed regularly when terminating the application, because some QObject descendants stored in the Singleton still tried to access the global application object - even as it already has been released.
Well, it was a lot of work to bring KI3U so far now, but now it finally seems to run fine and stable. Beneath, the issue list got shorter, too. The only remaining (important) thing is the GUI: I think there still is a lot to improve.
=-=-=-=-=
Powered by Blogilo