[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    KIO Error reporting [was: Re: Queued KMessageDialogs]
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-01-29 8:51:13
[Download RAW message or body]

>> A situation has arisen (I improved the error messages for kio) where we
>> need a queued detailedError message box. I am writing to get your stamp of
>> approval or comments.
>>
>> Originally I added a new queuedDetailedError() method - see patch.
>
>Looks ok. Added to CVS.

Ok.

>> btw. screenshots of the new error messages are here:
>>
>> http://yoyo.cc.monash.edu.au/~meddie/patches/errors/
>
>I think it is the wrong approach because it provides the user with
> suggestions and possible causes which are likely to be incorrect or
> irrelevant to a high degree.
>
>I think this falls into the category "The file does not exist or you do not
>have access to it.". This is your computer telling you that it has no idea
>what the problem is but you are supposed to know? Instead it should tell you
>"The file does not exist." or "You do not have permission to access to this
>file." whichever is applicable. Along the same lines it shouldn't say "You
>may have provided incorrect credentials" if you haven't provided cedentials
>at all.
>
>I'm all for better error reporting but only if it is truly better. That
>requires domain knowledge and that is something that either the slaves
>themselves or the application itself has. But KIO has not.

I have been getting this feeling from a number of places now. I hindsight, I 
really did rush this too much, and it's something I've been kicking myself 
about *hangs head in shame*. I was just too enthusiastic for all the good I 
thought I was doing.

I would like to hide the new system away for kde 3.0; it's a simple change to 
cvs. I realise that some i18n changes I made on Sunday (only a few, but they 
were vital, things like the headings for the html page version) are unlikely 
to be picked up for a while too, which would not be ideal, so I would like to 
revert those to (ie comment them out).

So, if there is no dissent, I will make the small changes to hide this away 
and to comment out the i18n strings I applied on Sunday so they don't 
surprise translators when (if? I don't know much about it) the i18n 
extraction happens again closer to the release... ok?

Then, when kde 3.1 opens up, I'll have another crack at it, with proper 
consultation this time. I think the above difficulties can be solved by more 
specific KIO::Error codes. The example above would be fixed by documenting 
the error codes to specify that the error_login_failed should be used any 
time that authentication details are truly incorrect, that way KIO can get 
the message right. I think this was how they were intended in the first 
place. Plus, Tim and I have been discussing the new ERR_SLAVE_DEFINED, and I 
think we can get slaves to pass all the info (error, detail, causes, 
solutions) through an agreed format in the errorText variable.

Thanks ,

Hamish
[prev in list] [next in list] [prev in thread] [next in thread]