Hiya guys,

Great stuff with the ktorrent!

I was thinking, I now have to cancel downloads to restart kde and such.

Perhaps it'd be an idea to split the download engine and kde-frontend up and built the download engine as a service and only have the kde-frontend connect to it to get status updates and cancel/add downloads and such. That way you wouldn't have to stop downloads/seeds when you restart kde or log out or something...

Just an idea.

Keep up the good work!

Download code and GUI are separate, so they could be split into a deamon and a front end (Allthough we would probably need to move some GUI code to the deamon.)

But this would complicate things a lot, we would have to use some IPC mechanism, to interface the two. It would be a lot of work, and there are more then enough things to do.

>But this would complicate things a lot
Absolutely. It would certainly not make it easier.

>we would have to use some IPC mechanism, to interface the two.
Again, true. There would have be some mini protocol orsomething for the two to interface.

>It would be a lot of work, and there are more then enough things to do.
I imagine so.

But it would be kick-a.. uhm, very cool. You could trigger some downloads and then it'll automatically go do that and restart while you reboot and continue when log out or log into another WM, close the kde-app-frontend,etc. And you could perhaps set a standard to which multiple clients could connect also: like a gnome front, console front, web-based front-end, etc..

If you have a good engine going in C++ code, it'd be a lot less resource hungry than the java and python download-engines that are around - and would certainly make a great service / daemon.

That said, the complications would probably prevent me as well from doing it if it were my project It's just hard!

But as you said, if you keep download code seperated somewhat from the gui-code, perhaps in the far future it might be a nice idea... I'd probably work on the other things now as well.

Cheers & thanks for the good work!

Another problem you might have is that the download code uses Qt's signals and slots. I don't know if they work in non GUI apps.

I'd say please don't ever do it:-) Split into application and service/daemon are generally a really bad idea. It generates lots of work for very little gain and the end result will end up less userfriendly for most users. Some very advanced users may utilize some benefit of a service/daemon, but for most it will only complicate and give problems.

The most likely outcome are lots of bugreports about downloads who don't stop when the user quits the applications and users unable to start downloads(service down). If you look at other programs using that kind of approach you don't exactly see stellar performance regarding stability and userfriendliness. One rely bad example are mldonky, but it's supposed to do torrents to so perhaps those who want the separation can try it instead.

not to mention that it would be rehashing from the moment that the daemon restarted... which would make ppl say "o my its messing up my system its so slow to start now >_< " etc.

I've been told that signals and slots can work in non-GUI Qt code as well.

The main issue is that the people who want a GNOME UI will **** and moan about the backend requiring Qt (as if there aren't enough console applications already which depend on GLib.)