KIO Error Handling update

Hamish Rodda meddie at yoyo.its.monash.edu.au
Tue Apr 16 13:36:18 BST 2002


>> Still on the to-do list:
>> * Make this change configurable (is this still wanted?)
>
>I don't see a point in making this configurable.

Ok.

>> * Work in a way for the system to determine what the current action was
>> (get / put / copy / move etc.)
>
>Hmm, for the KonqRun / khtml stuff it's obviously always a GET.
>But for the other cases ..... we don't have pseudo-rtti for jobs, the best
>way is probably to dynamic_cast the job pointer, if you have it, to find
>out what kind of class it is. Adding a virtual method would be better
> design, but BIC.

I'm now using qt's inherits() method, because I realised I was in a Job class 
when we call the error routine. I'm just sorting out some small details now, 
and giving it some testing.

>> * Add support for exec:/ URLs (any pointers for where to start -
>> did KActiveLabel get this functionality yet?)
>
>Yes.
>kactivelabel.cpp-void KActiveLabel::openLink(const QString & link)
>kactivelabel.cpp-{
>kactivelabel.cpp-   QStringList args;
>kactivelabel.cpp-   args << "exec" << link;
>kactivelabel.cpp:   kapp->kdeinitExec("kfmclient", args);
>kactivelabel.cpp-}

Ok; where would I add this capability to khtml (for error pages only, of 
course)?

Thanks,

Hamish.




More information about the kfm-devel mailing list