[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-30 23:17:53
[Download RAW message or body]

On Thu, Mar 30, 2000 at 08:56:42AM +0200, Matt Koss wrote:
> ----- Original Message -----
> From: "David Faure" <david@mandrakesoft.com>
> To: <kde-core-devel@kde.org>
> Cc: "Matej Koss" <koss@miesto.sk>
> Sent: Thursday, March 30, 2000 1:50 AM
> Subject: KIO progress info signals
> 
> 
> > Hi (Matt)
> >
> > Why are the signals all defined in the base class (Job) ?
> > I don't get the point. copyingFile() means nothing in, say, TransferJob
> > or DeleteJob, etc.
> >
> > This looks like the "old design" to me - why not go for the new
> > one and do job-specific stuff in the job-specific class ?
> >
> > Just wondering...
> >
> 
> The signals are in Job, so that progress stuff don't need to take specific
> action according to the type of job, but simply work with a KIO::Job class.
> Otherwise we would need to discern whether it is a CopyJob, DeleteJob etc...
> and according to the job connect only to its specific signals.
> 
> I thought that this is a quite good solution and jobs will only emit those
> signals which they need.
> On the other hand, the progress stuff can simply connect to all signals
>  some of them just won't come from some jobs ).
> 
> If you have some other ideas, please speak up.

Just an idea, not necessarily better:

if we create a class (let's call it, almost randomly, "observer"),
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.

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 hope that this weekend I'll be able to finish and test the progress at
> kioslavetest and caitoo, so that at least the first-type progress works.
> Then comes a GUI progress server, but it can be done later as it doesn't
> affect API.
Sure - but it affects the design so we have to keep it in mind ;-)

> Let's first finish API so that libs can be freezed.
Sure.

Suggestions, comments, critics about the above ?
I might dramatically overlook something ;-)

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today
See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2

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