kuiserver and kget2 issues

[Rafael Fernández López]

2007/2/5, Michael Pyne <michael.pyne at kdemail.net>:
>
> On Sunday 04 February 2007 17:55, John Tapsell wrote:
> > I don't think it makes sense to have a torrent kioslave
>
> It makes no sense at all. :)


Well, yes... but we are in the same case. KUIServer should show every
progress of every job, or at least an info message of what's going on. Now,
the transfer of a torrent can be paused or canceled (mainly), and that can
be done with the kuiserver only. So we have KTorrent, KGet for the same
thing. And KUIServer *POTENTIALLY* can do the same, but with every kind of
jobs, not only for downloading torrent files, and not only for downloading
files, but for showing any kind of job.

As you know kuiserver won't talk to any protocol at all. It just receives
signals and shows the data wherever needed. It can add support for actions,
for adding buttons, but results on a slot called on the KJob inherited
class, so that signal can be treated specifically.

The thing here, is that we have something like:

KTorrent < KGet < (potentially, not true right now) KUIServer + something

That "something" is "the thing" that talks to each protocol, creates a KJob
inherited class and updates the kuiserver with the progress of the download
(a torrent or whatever file we want). In order to have the full capabilities
of KGet, "the thing" should be able to multithread downloads, queue them,
and so on.

Regards,
> - Michael Pyne


Bye,
Rafael Fernández López.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070205/a25da35d/attachment.htm>