[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-04-01 13:11:08
[Download RAW message or body]

On Sat, Apr 01, 2000 at 09:40:39AM +0200, Matt Koss wrote:
> 
> Ok,
> 
> I thought a bit more about this and I like your idea.

Great ;-)

> Little summary, with additions :
> ----------------------
> 
> 1. Each job class will contain only those signals that it really uses.
> 2. KIO::Job will contain a singleton instance of Observer, that will pass
>     signals to GUI server.
Actually they don't need to store a pointer to the observer.
If there is only one observer, it has a static pointer and a static method
to get hold of it. The usual KTrader/KDirWatch/Scheduler/KSycoca/KMimeMagic
solution ;-) Wow, even only in kio, we use that quite a lot ;-)

>     It will look almost exactly as ProgressBase class, but it will not be a
>     widget, and instead of empty slots, each slot will use DCOP to pass signals.
>     Signals will have a job identifier, so that GUI server knows to which
>     progress dialog it should pass signals.
Yes. Didn't realise the similarity with progressbase. Good, less code to write
:)

> 3. Each job class will have a startObserving() method, that will connect    
>    signals contained in that job to observers slots.
>    This means that signals will get not connected in constructor and as such 
>     the top-level job will need not to disable observing in its child jobs.
>     Also apps like caitoo and kmail will get the same behaviour as proposed
>     earlier ( see DESIGN in kio )
> 4. KIO operations started from e.g. KIONetAccess ( = regular IO ) will call 
> startObserving() method right after creating job with e.g. copy(), move() 
> etc.

I don't quite like that. If "observing" is off by default, it means that you
get no GUI for most i/o operations - your seem to forget all the apps
that use KIO::some_operation directly, not using NetAccess, and that don't
want to deal with progress info. They don't want to have to write any
code for it, I mean. My guess is that they still want some progress info
to appear (using the progress-info server).
To keep the code in those apps as it is now, I think observing should be
default and only in some cases (custom progress info / subjobs)
we want to disable it.

But that is not a big issue. It simply depends on what we want the default
to be.
On the whole, this approach makes a lot of sense to me.

> I guess that we'll need to think more about the situation when we want
> progres not only from top-level job but also from its subjobs.
I think that this won't be 100% configurable. Like, in a CopyJob
you won't get - or you will get, to be decided - the progress info
of each file being copied. Do you think it's needed that the app
can specify whether it wants it or not ?
I would think this mostly depends on the GUI Progress Server's capabilities
(1 or 2 progress bars), not on the app's preference...

Do you have time for hacking this week-end ?
If not I'll try to do my best, but if yes I'll gladly let
you do it - or share the work.

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