More specific KIO Error Strings

[nf2]

Aaron J. Seigo wrote:
> On Sunday 30 March 2008, nf2 wrote:
>   
>> 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.
>>     
>
> probably not. it's just asking for more work for the slave owners and more 
> inconsistencies (not to mention more strings for translation).
>
>   

Well - they can still use the standard messages if they don't want to 
send something more specific.

>> This would be particularly 
>> useful when porting KIO to VFS-systems which already provide such full
>> (and translated) error messages.
>>     
>
> of course, the messages in KIO are also translated already.
>   

Sure, but i would like to hand over the GVFS error messages (if 
possible) - because from the users perspective i would expect the same 
error messages for the same problems desktop-wide. At the moment i can 
only dump the GVFS error messages to kDebug(), that implies loosing 
information.

The whole point of this would also be separating the interface from the 
implementation in KIO a little bit more, which should be good in any 
case i think.


>   
>> My proposal would be that KIO::buildErrorString() just returns the
>> errorText when it is prefixed with something like "{vendor} ".
>>     
>
> that would be a horrible, horrible hack. yes, it preserves the current API but 
> magic strings in parameters that change how things work is .. not very 
> pretty.
>   
Agreed.

>> That way we could also communicate the identity of the actual VFS-system
>> vendor.
>>     
>
> why does it matter to the user what the identity of the actual VFS vendor is?
> what are your exact use cases? 
> (evidently i'm missing something here, because i don't see the point =)
>
>   

I'm not completely convinced regarding this vendor string myself, but 
(as Kelly Miller already guessed right) i thought it might help with 
bug-reports etc...

Btw, i got a problem with mapping the error codes - as you can see in 
the function gIOError2KIO(): 
http://websvn.kde.org/trunk/playground/ioslaves/kio-giobridge/giobridge/giobridge.cpp?view=markup. 
It's a pity that VFS error codes haven't been standardized before KDE4 
and GVFS happened. Therefore i'd love to extend the list of KIO error 
codes, but i'm not sure if that would be appreciated. ;-)

Cheers,
Norbert