[Kget] Error handling in KDE 4.5

[Lukas Appelhans]

Am Mittwoch 27 Januar 2010 23:49:02 schrieb Matthias Fuchs:
> Am Mittwoch 27 Januar 2010 23:07:24 schrieb Lukas Appelhans:
> > Hey!
> > 
> > As anybody knows our error handling in KDE 4.4 is far from optimal... we
> > 
> >  leave the plugins pretty  much alone handling those errors (and not
> >  every plugin reports much...).
> > 
> > For 4.5 we should improve the situation...
> > So my idea was to add some setError(Job::Error, const QString
> > 
> >  &errorMessage); to the transfer-class, which would handle the
> >  notification + give solutions on how to solve the error...
> 
> I completely agree on that, though imo we should have multiple setError
> methods, e.g. one for many files. The Metalink-plugin e.g. waits until all
> files are verified and then shows a dialog that lists all files where
> verification failed. That is to avoid showing multiple dialogs to the user.
> So another method could be
> setError(Job::Error, QList<KUrl> affectedFiles, const QString
> &errorMessage);
Well I don't think so...

In this case we should set the error inside the filemodel, but not for the 
transfer...
> 
> > For example...
> > our transfer does setError(Job::DiskFull, i18n("Your harddisk is running
> > 
> >  out of memory"));. With that information we automagically show the error
> >  in the GUI and show an option to 1) move the transfer's files to
> >  somewhere else and 2) to continue downloading... (+ we could detect
> >  automagically if the user removes files from the disk and resume the
> >  transfer).
> 
> Hmm imo it should not be the transfers task to care about the disk
> capacity, that should happen 1) before the transfer is started 2) after
> totalSize is emitted 3) periodically while transfers are running. Though
> then would still be the problem of transfers that create the files with
> the totalSize ... So maybe we could have a class that checks for the size
> and the transfers do that themselves in case 1) (here the new
> transferdialog) and in case 2) while case 3) would be handled elsewhere.
Ok true... :) I was just giving an example :)

Lukas