More specific KIO Error Strings

[Aaron J. Seigo]

On Monday 31 March 2008, nf2 wrote:
> Aaron J. Seigo wrote:
> > 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.

the "something more specific" part is what the error string is for.

> >> 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.

i think we all agree on that. but you're actually suggesting making it so that 
KIO doesn't always return the same error strings, which is exactly the 
opposite of consistency.

> 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.

> 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.

> >> 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...

there are other ways of getting at this information, and your proposal comes 
at the expense of consistency. not worth it, imho.

could you just put the vendor information in the error text passed to the 
error() method?

> 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/gio
>bridge.cpp?view=markup.

yep.

>It's a pity that VFS error codes haven't been 
> standardized before KDE4 and GVFS happened.

would've been nice. kio's error codes predate GVFS, so it should be evident 
where that conversation should've started.

> Therefore i'd love to extend 
> the list of KIO error codes, but i'm not sure if that would be appreciated.

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_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?

G_IO_ERROR_READ_ONLY also seems to map to existing KIO error values, such as 
KIO::ERR_CANNOT_OPEN_FOR_WRITING. the error message might again help here.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080331/94e3f642/attachment.sig>