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

List:       kfm-devel
Subject:    Re: KIOSlave errors an konqueror's handling of them
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-01-25 14:08:32
[Download RAW message or body]

>On Friday 25 January 2002 13:06, Hamish Rodda wrote:
>> Very well... should I document that somewhere, or rename the const QString
>> &_text to const QString &_hostname (or even better, const QString &_url)?
>> In fact, the app should know the URL, so maybe it's not needed at all.
>
>The "additional text for the error message" isn't _always_ the hostname.
>Or not always the URL - it's sometimes one or the other. For instance a
>timeout should show the hostname only, since it's the host that has a
>problem, whereas a "file doesn't exist" should show the entire URL. And some
>other messages can use that additional text as a field for additional info,
>e.g. in more flexible error codes. This all about flexibility, don't rename
>it to something as strict as "hostname" or "url".

Ok. Perhaps I should document what is to be passed for each error message 
somewhere.

>> Is ERR_SLAVE_DEFINED going ahead for 3.0? If so, can I add the enum value
>> at least so it can be worked on...
>
>I thought whoever (i.e. you?) wanted it in already added it. I'm fine with
> it being added.

Not me... I've contacted the author to get his latest work though and see if I 
can review & commit.

>> WRT fancy error messages, I was talking about a nicely formatted html page
>> with the error type (eg. timeout) and a verbose, friendly message such as
>> "The request was not completed because the time limit for the request was
>> reached. This could be caused by blah blah blah." This would be handled at
>> the konqueror level, getting error() rather than errorstring(), and
>> loading the relevant html page. This would be configurable.
>
>Well, that sounds great and is exactly the error:// stuff we were talking
>about on kde-cvs. If you think about it: how is Konqueror going to show that
>HTML in khtml? It can't just stick it in a temp file and open khtml on it,
>that would give a wrong URL in the location bar. Hence the idea of passing
> an error:// URL (something that doesn't exist yet) to khtml, which would
> generate the error message from that. Indeed, by passing the error code in
> the query, you can write nicely formatted error messages for each error
> code. If you feel like working on this, please do so, my todo list is
> growing much faster than I can empty it. Thanks ;)

I will take a shot at it... I may have a few questions along the way, of 
course.

Hamish.

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