More specific KIO Error Strings
nf2 at scheinwelt.at
Mon Mar 31 20:23:03 BST 2008
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
> 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
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.
More information about the kde-core-devel