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

List:       kfm-devel
Subject:    Re: progress info
From:       Tobias Anton <TA () ESC-Electronics ! de>
Date:       2001-07-26 13:07:53
[Download RAW message or body]

On Wednesday 25 July 2001 19:13, Simon Hausmann wrote:
> On Wed, Jul 25, 2001 at 05:39:34PM +0200, Tobias Anton wrote:
> > On Wednesday 25 July 2001 16:04, Simon Hausmann wrote:
> > > On Wed, Jul 25, 2001 at 03:50:51PM +0200, Dirk Mueller wrote:
> > > > On Mit, 25 Jul 2001, Simon Hausmann wrote:
> > > > > > So it appears to me that I have to avoid emitting the jobid in
> > > > > > the started() signal to make the embedding framework (i.e.
> > > > > > konqueror) listen to this signal. is that correct ?
> > > > >
> > > > > Yep :-)
> > > >
> > > > What is expected to break when I don't provide the Jobid anymore ?
> > > > I mean thats like breaking binary compatibility - apps that rely on
> > > > the old behaviour will crash or stop working. :-(
> > > >
> > > > Arghhh.
> > >
> > > I don't think this will cause any problems at all. Any application
> > > connecting to the started() signal and dereferencing the passed job
> > > without a previous null pointer check is horribly broken and IMHO not
> > > worth to work around. It's even documented ;-)
> >
> > This is a functionality incompatible change, though. Binary compatibility
> > implies functionality compatibility. And we don't know how many apps
> > using khtmlpart are out there (the ones that don't crash) that won't be
> > able to display progress information any more.
> > IMHO, we should wait until 3.0 before stopping to emit the jobid.
>
> Where is the functionality change?
if the program displays the job's progress info, it will stop doing so.


> We continue to emit the started signal (as required, actually) . The only
> difference is that as argument to the signal we no more pass a valid
> reference to a KIO::Job object but a null pointer. The documentation of
> kparts clearly says that this is ok for parts that do not use KIO or not
> want to use it for progress information.
You're right. Especially when the restoreURL is used, a null pointer is 
emitted anyway, so an application cannot avoid a check for it.
But in openURL, KHTMLPart does emit a valid kio-job-pointer both in 2.0 and 
in 2.1.

I'm just pointing out why we should be careful, you know that I already 
caused problems with binary compatibility.
Generally speaking, changing the application is better than changing the 
library, because there are more dependencies on the library.
Dunno about konqueror plugins, however.

What about the following idea: (that's how i did it)
Use the progress info of the job unless part emits progress information for 
the first time. After all, the job, if present, will always terminate 
_before_ the part is finished.

As soon as the part emits its first progress info,
konqueror could stop displaying the job's, and take the part's instead.

Cheers,
Tobias

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