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

List:       kfm-devel
Subject:    Re: KIO/KHTML Error Handling Update
From:       Hamish Rodda <meddie () yoyo ! cc ! monash ! edu ! au>
Date:       2002-01-27 13:29:42
[Download RAW message or body]

>On Sunday 27 January 2002 13:40, Hamish Rodda wrote:
>> Let me know one way or the other, whether it's commit or revert...
>
>Looks good to me, I think this should go in - but maybe wait for Dirk's
>approval.
>
>BTW Dirk: when I said "ok to commit" I was under the impression it was about
>the error:// stuff mainly, which _is_ a bugfix for the currently bad
> handling of errors in konqueror (the "get() after stat()+error" problem).
> Didn't realize there would be so much new i18n stuff and code in KIO. But,
> hmm, it's in now, and if translators don't like much new strings, they hate
> it even more when those new strings get removed, after they actually
> started to translate them :}.

I too didn't realise how big it would get... seeing there are only a few 
errors which are normally visible. I did post to i18n-doc telling them not to 
start yet at the start of today, so unless there were people translating away 
sat. night I doubt their removal will annoy anyone.

BTW did you take a glance at the error:// stuff? was it as expected?

>> I don't want to press my luck, but to resolve the ioslave error reporting
>> deficiency once and for all, could KURL *requestURL be added to the
>
>slavebase
>
>> error() call with a default argument of 0L?
>
>The problem is to implement passing new data via the KIO protocol without
>breaking runtime compatibility with KDE-2 ioslaves (which Waldo ensured up
> to know). I don't think this is possible (without huge hacks) - I should
> say, I don't think it's worth it. In many cases the URL can be grabbed from
> the Job anyway.

That's true, perhaps I should look at that and see if I can come up with a 
patch. BTW if they are compatible, why can't ioslaves from old builds be run? 
I have a few stale ioslaves (fish for example) that doesn't work.

>> Also I was thinking that KIO::Job
>> should be able to remember the job type by a protected method
>> setJobType(int type) which is called from derived classes...
>
>And we'd have an enum for job types? Doesn't make it very extensible.
>Apps are allowed to inherit Job to create their own specific job, and then
> it won't be in the enum. What would be the use of the job-type in fact ?

"Access was denied while trying to {copy, move, delete} the resource". It 
would be nice to have for about 25% or more of the strings I added.

>> and that the .protocol files
>> could have a flag added to specify if they are network-based protocols or
>> not.
>
>Yes, looking at your code this looks necessary. You can easily add that,
>editing all .protocol files, and adding the code to

Shall look into it.

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