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