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

List:       kde-devel
Subject:    Re: Meta refreshes not followed
From:       David Faure <faure () kde ! org>
Date:       2005-01-24 20:59:48
Message-ID: 200501242159.48735.faure () kde ! org
[Download RAW message or body]

On Monday 24 January 2005 21:41, John Morton wrote:
> On Tuesday 25 January 2005 00:45, David Faure wrote:
> >  On Monday 24 January 2005 11:24, John Morton wrote:
> >  > A little odd; I would have though that KHTMLPart would have put together
> >  > this slot and connection by itself
> >
> >  That's because you're only thinking of meta-refreshes. Those it could
> > handle, but what about clicking on links? For those the openURLRequest
> > signal is needed anyway (since the link might point to something with
> > another mimetype, e.g. a PDF, which khtml can't handle itself). So once we
> > have a mechanism for opening a url, better use it for everything. It gives
> > us e.g. the rotating wheel and the "stop" button being enabled in konq,
> > which wouldn't happen if khtml handled the meta-refresh all by itself.
> 
> I'm not saying that it's not a good idea to have something like the 
> openURLRequest signal, I'm just surprised that KHTMLPart doesn't have a 'grab 
> the url by whatever means and figure out what to do with it' slot (that I 
> could see, anyway) and a connection from openURLRequestDelayed to it. I guess 
> there could be sufficient cases where you'd want to roll your own slot, but 
> in that case updating the KHTMLPart documentation to say so might be a good 
> idea.

Ah and you would simply have to connect to that slot? Sounds good.
But connecting openURLRequestDelayed to KHTMLPart's openURL( const KURL& )
should work, in fact. The second argument from openURLRequestDelayed
will be discarded.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]