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

List:       kde-core-devel
Subject:    Re: KIO progress info signals
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-03-31 9:27:08
[Download RAW message or body]

On Fri, Mar 31, 2000 at 11:43:34AM +0200, Matt Koss wrote:
> > Just an idea, not necessarily better:
> >
> > if we create a class (let's call it, almost randomly, "observer"),
> 
> I guess that Stephan's suggestion comes always handy :-)
Yes :)
> > that has all kind of possible _slots_ for progress info, then
> > the job's constructors can connect their signals
> > (which they know about, obviously), to that "observer" class.
> 
> IIRC this was the former design, but instead of observer we had progress
> dialog. I thought that this way ( job connects itself to progress/observer was
> stated as bad ). On the other hand, I personally was not against it.
I didn't realise that this what we had, but that's no reason, by itself,
to state it as bad ;-) It worked :)

> If the job constructor connects to the observer automatically, then also all
> subjobs would do it and progress server would get a whole lot of signals,
> right ?

Not necessarily. If we have this "disableProgressGUI" call, then the
main job (e.g. CopyJob) could use it when creating subjobs, so that you
don't see all the details of what's going on - although with
progress info, the more the merrier. I could even imagine two progress
bars, when copying a directory: one with the overall status and one with
the current file copy's progress. But that's another issue. The point
is that if we don't want that, the main job can disable the subjob's
progress info GUI (I add "GUI" because the signals still get emitted)

> BTW, in both solutions the GUI progress server need to somehow identify
> which observer sent him the signal and forward it to the corresponding
> progress dialog accordingly.
Ah - I didn't realise the GUI server handled more than one dialog boxes.
I guess the signals, much like the existing signals (result etc.) should
contain the Job * pointer. But then how to know which jobs are
part (subjobs) of which ? Perhaps the solution would be that the main
job forwards the interesting signals from its subjobs... That would solve
both problems (not too much info, and finding which Job it's about).

> OTOH when the observer connects to the job, it connects only to the top
> level job and thus gets only signals from that job, am I right ?
Hehe, we got the same idea, yes.

Note that this implies something on where we put signals.
For instance, putting "creatingDir" in mkdir is IMHO useless.
It is only (perhaps) useful if it is put directly into CopyJob when
it creates a dir -> no forwarding needed, and somebody using
KIO::mkdir() manually doesn't care about that single "creatingDir" signal,
right ?

> > The point would be more that it's more modular if we put the signals
> > in the respective job types, and it also makes it clear which jobs emit
> > which signals - which is handy for apps that want to handle progress info
> > themselves : you know which signals are going to get emitted without
> having
> > to read extensive docu on them in KIO::Job, nor reading the slave's code.
> 
> I see your point. I have also thought a lot about this, and at first I have
> put only those signals that are really emited to the corresponding job
> classes.
Yup. Saw that - and was disappointed by the change afterwards ;-)

> But then I didn't see other solution as put all signals into KIO::Job.
> We can easily state in the documentation in particular classes which signals
> are emited from it.
Not as clean ;-)

> Let's talk a bit more about this and create a good design, rather then
> blindly code something that will later be redone completely.
Definitely. That's the point in the new KIO.

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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