[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:47:37
[Download RAW message or body]

On Sat, Apr 01, 2000 at 03:33:11PM +0200, Matt Koss wrote:
> >> 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.
> 
> That's fine, but I simply don't want all the connecting code in the job
> constructor.
> Once the signals are connected, it's late to stop observing, isn't it ?

Hmm, indeed...... it would be stupid to connect and then disconnect...

> The solution would be to pass a flag in operation methods ( copy, move ... )
> but I don't like that at all.
> Any idea ? Or am I missing something ?

Hmmmm. I had overlooked the API problem.
I see no other solution than enableProgressInfoGUI() (hmm, that's not
better than startObserving() ;-))  but that means most apps won't
get progress info... unless we port them once again.
If we don't want that, and additionnal flag to all operations
(with default value being true) would be the way to go.
I would have preferred to avoid that too, but in fact it makes sense.
When requesting an operation to KIO, you have to tell it how you want it :
with default GUI or not.

> I've got time, no problem.
> If it's possible, I would like to leave the observer class on you
> ( particularly sending stuff to GUI server via dcop ),
> 'cause I am not very familiar with dcop yet.

Ok.
Did we decide which app would be the server ?
A new daemon (huh) ? kdesktop ?
The initial plan was kioslave, but that's part of kdeinit now.
So perhaps it would be a new daemon, but forked from kdeinit of course.
kioprogressinfoguiserver. Gosh. I need to shorten that.
;-)

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