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