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

List:       kde-core-devel
Subject:    Re: optimizing CopyJob, unconnected signals ?
From:       Matt Koss <koss () miesto ! sk>
Date:       2000-11-13 9:47:41
[Download RAW message or body]

On Sunday 12 November 2000 10:33 pm, David Faure wrote:
> On Sunday 12 November 2000 22:47, aleXXX wrote:
> > On Friday 10 November 2000 15:59, David Faure wrote:
> > >On Friday 10 November 2000 16:05, aleXXX wrote:
> > >> Hi,
> > >>
> > >> CopyJob emits signals like copying(...), moving(...) and others.
> > >> I could not find any connect(...) call which connected them to any
> > >> slots. Can they be removed ?
> > >
> > >No, they are necessary for the Undo feature.
> > >Look at libkonq/konq_undo.cc for the connects.
> >
> > I had a look. There are only the signals copyingDone and movingDone
> > connected.
>
> Oh, indeed. Yes, copying() isn't used indeed.
> It's only there because ProgressBase knows about it and connects to it, but
> we don't use it this way anymore. The whole reason for the ProgressBase,
> StatusbarProgress, and DefaultProgress classes were to provide several ways
> to connect to a job's signal, for instance to get the signals directly
> connected to a statusbar. This is from the previous KIO design and is not
> used by any KDE app AFAIK, since we have kio_uiserver.
> I just don't know if we want to get rid of that or leave it. It's Matt's
> stuff, really....

I understand that these signals are in place for creation of customized 
progress dialogs. This way you get the signals for your customized dialog 
automatically.
kio_uiserver can be used only for the common dialog or default progress 
dialog.


	Cheers

		Matt


>
> > Additionally I made some measurements on my system.
> >
> > Calling a member function 1.000.000 times took 0.11 seconds, emitting a
> > signal connected to a slot which does exactly the same 1.000.000 times
> > takes 6.5 seconds, so in tight loops signals/slots are significant for
> > performance.
>
> Ok, good to know. But what about emitting a signal that isn't connected to
> anything (as it's the case with copying()). Does that take much time ?
> Hmm, I guess it's something in between, since it goes half the way.
>
> > David, can you please have a look in jobclasses.h which signals must be
> > "public" (i.e. are intended for external use like e.g. undo) and which
> > are only for internal use and could be potentially replaced by direct
> > calls, I will do the rest if you agree.
>
> I don't see signals that can be replaced with direct calls. Keep in mind
> that in KIO there are subjobs and master jobs. The subjob emits a signal,
> the master job connects to it, either for its own purpose (calculating
> progress) or for calling a method in observer - or most of the case, both.
>
> One unused signal from the slaves is gettingFile(), but it's already been
> removed from the main slaves (the ones in kdelibs). I'll clean the
> kdebase ones.

-- 
Matt Koss
e-mail:  koss@miesto.sk

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