More specific KIO Error Strings

[nf2]

Aaron J. Seigo wrote:
> On Monday 31 March 2008, nf2 wrote:
>   

>> At the moment i can 
>> only dump the GVFS error messages to kDebug(), that implies loosing
>> information.
>>     
>
> you could "dump" the GVFS error message into the error string. that's what it 
> is there for.
>
>   

Hmm... Looking at KIO::buildErrorString(int errorCode, const QString 
&errorText)
(http://websvn.kde.org/trunk/KDE/kdelibs/kio/kio/global.cpp?view=markup) 
it seems that internally the "errid" sent by the slave seems to be the 
actual message, and the "text" is just the file-name, protocol-name or 
host-name to be filled in. Therefore - in most cases - i can't put error 
messages or vendor information into the error text (Unless i use 
ERR_UNSUPORTED_ACTION, but then applications cannot react on the error-code)


>> 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.
>>     
>
> this mapping needs to happen somewhere for a consistent user experience. 
> moving it from kio to somewhere else doesn't fix anything, it just moves the 
> problem to some other place.
>   

True - but i still think defining error messages in the 
VFS-implementation allows a bit more flexibility (see below).

>
>   
> assuming the errors are ones that matter to percolate up to the user (there 
> seem to be a few there), new error codes can be added to the KIO::Error enum. 
> there's lots of room remaining.
>
> which error codes would you like to see added? 
>   

Not sure yet - there are a lot that can be mapped, but not all of them...

> NOT_MOUNTED, ALREADY_MOUNTED? those are specializations of 
> KIO::ERR_COULD_NOT_MOUNT or KIO::ERR_COULD_NOT_UNMOUNT, no? couldn't that 
> information be provided in the error message?
>   

That's actually a good example what i'm trying to fix. The predefined 
text for KIO::ERR_COULD_NOT_MOUNT is:

"Could not mount device.\nThe reported error was:\n%1".

This is quite limiting. What if it's a network or FUSE mount?

In GIO/GVFS they made the - i believe - wise decision that error codes 
are only for application internal "exception handling" - the more 
detailed "to-display-messages" are defined separately in the backends. 
Of course it makes sense to have a set of standard messages, but picking 
the right one could still be done in the backend, and there might be 
more than one message per error code to choose from.

Regards,
Norbert