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

On Sat, 01 Apr 2000, David Faure wrote:
>On Sat, Apr 01, 2000 at 09:40:39AM +0200, Matt Koss wrote:
>> 
>> 
>> 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 ;-)
>

Yes, it can be done like this.

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

Exactly.

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

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 ?

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

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.

		Regards

									Matt


-- 
Matej Koss	e-mail: koss@miesto.sk
Kosice		 ICQ# : 19344305
Slovakia

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