More specific KIO Error Strings
nf2
nf2 at scheinwelt.at
Mon Mar 31 09:49:47 BST 2008
Andreas Hartmetz wrote:
> Am Montag, 31. März 2008 02:15:17 schrieb nf2:
>
>> At the moment the KIO error messages are limited to the pre-definded
>> messages in KIO::buildErrorString(int errorCode, const QString
>> &errorText). The errorText doesen't contain a full description of the
>> problem, but rather the host-name or file-name to be inserted into the
>> pre-definded messages. I wonder if it would make sense to allow slaves
>> to construct error messages themselves. This would be particularly
>> useful when porting KIO to VFS-systems which already provide such full
>> (and translated) error messages.
>>
>> My proposal would be that KIO::buildErrorString() just returns the
>> errorText when it is prefixed with something like "{vendor} ".
>> That way we could also communicate the identity of the actual VFS-system
>> vendor.
>>
>>
> What an incredibly useful method :) </irony>
> Practically speaking all ioslaves are in KDE svn so IMHO (and there are people
> who like to protect BC/SC a lot harder) a simple behavior change like that
> would be OK.
> But would that make this apparently quirky and unintuitive to use method
> ("build a string based on, you know, this thing and the other thing") merely
> a bit better or would it be *good*? If it wouldn't be good I say deprecate it
> and introduce something that you/we can be proud of :)
>
>
>
Yeah, overloading the error() callback would be prettier. :-)
void SlaveBase::error(int _errid, const QString &_text )
void SlaveBase::error(int _errid, const QString &message, const QString
&htmlDescription, const QString &vendor).
But the problem is that then the second parameter has a different
meaning, which sucks a bit too. What about a different function name?
void SlaveBase::customError(int _errid, const QString &message, const
QString &htmlDescription, const QString &vendor).
Norbert
More information about the kde-core-devel
mailing list