About error messages names in KDE

[Waldo Bastian]

[Apologies to kde-usability for the implementation issues in this mail]

On Wednesday 05 February 2003 13:27, Hamish Rodda wrote:
> Waldo Bastian wrote:
> > On Wednesday 05 February 2003 09:04, Hamish Rodda wrote:
> >> At the moment I have a new kio class called KCustomError, which feeds
> >> detailed error information back to the calling app through XML.  I've
> >> integrated it to display properly in khtml and through dialog boxes,
> >> with a collapsable "details" button hiding advanced or in-depth
> >> messages.
> >
> > I must say that I think the current "details" button in error dialogs has
> > it backwards: it doesn't provide details about the error, it provides
> > generic hints about what could be wrong.
>
> If you're talking about my patches from way back that information was shown
> in response to the use of the standard KIO error codes.  I thought that
> having some hints (and I intend to reduce the amount of speculation
> presented as default ;) would be better than nothing, but this is easily
> removed if that's the consensus.

No, it's not that bad, I just wanted to raise the issue.

> > If I get an error about "Couldn't read file." I expect that details gives
> > me an explanation of why it can't read the file, not some wild
> > speculation about what COULD be wrong.
> >
> > Unfortunately I am very much aware of the enormous development effort
> > that would be required to actually gives such an accurate explanation.
>
> The code I wrote makes it possible to confer that information to the user,
> thus putting the onus back on the maintainer of the ioslave to convey that
> detail (see attached header... this would also get support for the proposed
> kde error codes this thread was originally about).  We can then deprecate
> the old KIO error codes.  I would hope that making it easy for ioslave
> maintainers to add detailed messages like this might motivate them to do
> so.

Well, the old KIO error codes are pretty much needed in order to process 
errors by software. They should either be extended, or some flag should be 
added to tell the IO-slave what kind of error code it should generate.

We do the latter already for http, where you can get a normal error code or a 
html page describing the error.

Looking at the code in kio I think it is possible to extend the current
error messages though, by adding:

  SlaveBase::error(int _errid, const QString &_text, const KCustomError &);

for use by IO-slaves. And add:

  error(int, const QString &, const KCustomError &);

as a new signal to SlaveInterface.

Might be usefull to let KCustomError derive from KShared together with a
typedef KSharedPtr<KCustomError> KCustomError::Ptr;

That would make it easier to pass those errors around without having to copy
them. Otoh, error processing is unlikely to be very performance critical 
anyway.

> Additionally, the majority of error messages that a user is likely to see
> (imho from file:/ and http://) shouldn't be too hard to port over.

I think errors caused by failed QFile::open() calls in applications (as part 
of a File->Open operation) are another good candidate. Maybe we should also 
provide a function solmewhere then that tries to open a file and either
returns an open QFile or a KCustomError based on the actual problems 
encountered when opening the file.

> I would also like to present the standard error messages here for
> discussion before going ahead with using them.

Yes.

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com