[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:       David Faure <david () mandrakesoft ! com>
Date:       2002-01-25 12:50:07
[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".

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

> 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 ;)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david, http://www.konqueror.org
KDE 3.0: Konquering the Desktops

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