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

List:       kde-core-devel
Subject:    Re: KIO progress info signals
From:       "Matt Koss" <koss () miesto ! sk>
Date:       2000-03-31 9:43:34
[Download RAW message or body]

----- Original Message -----
From: "David Faure" <david@mandrakesoft.com>
To: <kde-core-devel@kde.org>
Sent: Friday, March 31, 2000 1:17 AM
Subject: Re: KIO progress info signals


>
> 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 :-)

> 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.

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 ?
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.

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 ?

> AFAICS, this observer would only need to exist as one instance
> (the singleton pattern), because it's a bit the "client view of the
> progress info server". Every time a slot of his gets called, it just
> forwards the info to the server. Of course we would have a way to
> disable that, for apps that want to handle the progress info themselves.
> (like Job::disableProgressInfoGUI - TODO, find a better name) ;-)
> -> it's on by default for most apps, as was the plan.
>
> > If you think that progress stuff should discern between various Job
types,
> > we can do that too.
> 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.

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.

Let's talk a bit more about this and create a good design, rather then
blindly code something that will later be redone completely.


            Regards

                                                Matt

------------------
Matt Koss
koss@miesto.sk

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