[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Kget integration
From:       David Faure <faure () kde ! org>
Date:       2002-03-28 15:50:52
[Download RAW message or body]

On Wednesday 27 March 2002 23:14, you wrote:
> Hi David,
> 
> Sorry if i came back always to you but you are my only link..

Well, that's what mailing-lists are for ;-)
Please subscribe to kfm-devel (cc'ed), that's where questions related
to konqueror and kio are best answered.

> thanks for your answer to be honest what I'm looking for is to find a deep \
> integration between kget and konqueror i.e.  not only to give with the right menu \
> an "open with kget.." but also to lunch kget when i left click on a link like  \
> ftp://ftp.kde.org/abc.tar.gz instead opening the standard "Save to disk..   Open  \
> Cancel" windows. Is the development of a plug-in the right way? or i need to \
> intercept  calls between konqueor and kdelibs? 

A plugin will need some code to be added to Konqueror or kio anyway,
so the difference isn't big (but the plugin type of architecture is certainly
preferred). Please look into how to integrate this into Konqueror without modifying
it too much - a standard KLibFactory-based solution would do this quite easily.

> Second things I've wrote 2  email to konold@kde.org (compliant on what i found on \
> the web site) regarding the caitoo web site @ http://devel-home.kde.org/~caitoo/  \
> but unfortunately i didn't get any answer is the right guy or the email address is \
> outdated?

Right guy, but not always very responsive. Try again anyway, some mail
got lost around March 15 due to server problems.

> in 2 words I've decide to rollback because is my
> intention to add a bandwidth management and  download splits in segments and i \
> didn't find a way to do with jobs

Then what about adding the missing stuff to jobs?
Let's do this the opensource way: please consider KIO (and all of KDE in fact)
as a white box, not as a black box. Look into how it works, and suggest
the necessary changes for integrating download management. I think this
is a much better way than duplication KIO's functionality in kget itself,
which can only lead to maintainance headaches and hard to find bugs
(at the moment if an FTP-related bug is fixed in kio_ftp, we know for sure 
it fixes _all_ of KDE apps accessing FTP. If kget has its own FTP code, then
it won't get such a fix, and we'll still have people reporting that FTP site x.y.z
still doesn't work for them, w/o being able to understand why... Just an example,
there could be 10000 more such examples ;).
The best way is really to look into the missing bits in KIO for this (additional \
signal? virtual methods in a new interface class? new bool? new functionality in \
TransferJob, e.g. splitting in segments? There are many ways to extend kio.), and \
suggest the changes on kfm-devel (or kde-core-devel, at your option) - either before \
doing the changes (discussing the best design) or after (posting the patch).

Thanks.
--
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today


[prev in list] [next in list] [prev in thread] [next in thread]