Hi,

I've used KTorrent for a long time on Linux, and consider it to be the best torrent software for any platform. It has all the features I need (with the possible exclusion of a WebUI) and no bloat. So first of all, thanks!

However I am switching to Mac OS as my primary platform, and miss a number of KDE apps, most of all KTorrent. I think a straight port is impossible currently given the state of KDE/Qt4, but I've been toying with the idea of porting the torrent library (libktorrent) to Mac, then building a Cocoa front-end to it, I gather in much the same way as KTorrent is a Qt/KDE front end to libktorrent.

Having made some initial attempts to get things to compile, I've found that libktorrent itself depends on a number of Qt and KDE functions, namely QString, QStringlist, QByteArray, KURL etc, and the Qt signal/slot system.

I was curious as to whether these various functions were essential to the functioning of libktorrent, or whether standard C/C++ functions and types could replace them. I note particularly a number of more lightweight implementations of the signal/slot system for ISO C++, namely sigslot, slotsig, and (the slightly heavier) Boost framework.

At the moment I'm getting a Qt 4.2.1 framework up under XCode and attempting to get libktorrent to build, but if I am successful, a longer term goal would be to make libktorrent independent of Qt and KDE, making Mac and Qt-less linux deployment easier. I think a full Objective-C rewrite is a bit excessive, and would make it difficult for me to manage continuing evolution of the libktorrent code, but I think a platform independent libktorrent would fill a current OSS gap, ie the lack of a GPL bittorrent library with DHT and encryption support and high speed (I really like KTorrent ) as well as a similar gap on the Mac.

I would appreciate any thoughts or input the developers particularly, but anyone else with an opinion had, on either the need, practicality or use for this. I am aware of the fact that KDE 4 will run on the Mac, but having just discovered the Cocoa Framework and Obj-C, am quite enthusiastic about what the native Mac dev tools can do.

Regards,

Ryan

Qt's Signal/Slot mechanism is used heavily. As well as a whole bunch of utility classes like QString, QValueList ... I guess those can be replaced by classes from the standard library (std::string, std::list, std::map).

KIO is also used for tracker requests, but this could be replaced by a more portable library (curl maybe).

It's gonna be a big job if you want to get rid off all Qt and KDE code. We split things up in a library and an application and plugins, but it was not my intention to make the library a generic torrent library, which could be used by other clients.

I started this to make a KDE application which does bittorrent not to make a bittorrent engine to use in a KDE application.

Thanks very much for your comments. That's fair enough, it certainly makes sense to use all the facilities available on your system.

At this stage I think it might be easier to write a library in standard C based on the logic in your code.

Regards,

Ryan

You are not exactly looking for the shortest path to your goal here.

I can agree with a straight port to Mac is impossible currently given the state of KDE/Qt4, and not made easier by the fact that KTorrent still are a KDE3/Qt3 application and porting to KDE4 has not yet started.

It would be much simpler to start with the current KDE3 version of ktorrent and use Qt3 for Mac. Then you have to use Qt calls in stead of KDE ones where possible. For the remaining you have to port some small parts of the KDE libs, mostly parts of KIO I'd guess.

Thats true, but Qt 3 is difficult to integrate with XCode, and is a monolthic build making the redistribution size huge. Qt 4 is better, ie you can separate the Core and Gui libraries and create Mac Frameworks, but again trying to bundle all those dependencies into a single .app bundle in a reasonable size to support a platform without native Qt is a nightmare.

I'm not really aiming for the shortest path, rather the one that provides the most portable and highest performing library under Linux and BSD/Darwin. Currently the plan in taking over an abandoned C torrent library as a base, and rework it to support DHT and encryption.