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

List:       kfm-devel
Subject:    Re: Kget integration
From:       Patrick <pch () valleeurope ! net>
Date:       2002-04-01 11:24:00
[Download RAW message or body]

OK David i will follows your suggestions and rollback to KIO-jobs


Patrick


On Thu, 2002-03-28 at 16:50, David Faure wrote:
> 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]